Command line centric? well if you do not like this you can easily go for configuration file option.

Config::General and Config::Any can be valid options and if you want configuration in JSON you can go with JSON::MaybeXS

But really you do not have to choose between command line options versus configuration file: you can have both!

I'm really a fan of The Dynamic Duo --or-- Holy Getopt::Long, Pod::UsageMan! and I suggest you to use this approach as base. Then you can specify the possibility to import the configuration via config file overriding option passed via command line: put this very clearly stated in the documentation and if possible warn the user about this behaviour of your application.

You can also use Modules as configuration files if it is the case.

As pseudocode I suggest something like:

# declare all aribles used by arguments or config files soon, specifyi
+ng their default values:

my $arg_color = 'red';
my $arg_limit = 1024;
my $arg_config;



# use Getopt::Long to parse command line arguments: die if this goes b
+ad 

GetOptions(
  'color=s'   => \$arg_color,
  'limit=i'     => \$arg_limit ,
  
  'configuration => \$arg_config,
) or pod2usage(-verbose => 1) && exit;


# apply eventual configuration

if ($arg_config){

   # warn about option that be ovveride and import the configuration
   ...
}

# check that all options are valid warning which one is incorrect, ret
+urn false and die

&check_config or die "Options are invalid";
[download]

L*

PS you can be also see default option How do I process many (conflicting) command line parameters? GetOpt Organization and getopt::std to pass arguments to command line help to find some inspiration