There are several modules that offer a configuration option to build XS or PP version of the module. They are usually handled by checking the existence of C compiler, and many provide an option for Makefile.PL or Build.PL to prefer the pure perl build, but the options are not standardized, and there are: --no-xs, --pp, -pm and --perl_only.
i.e. https://github.com/tokuhirom/cpanminus/commit/51737b5aaaea0171e2e36ac30b0a1a68b4e78d8d#L1L845
It would be useful if installer and builder can agree on the protocol to prefer Pure Perl, since there are many occasions where you want to build pure perl version for the bundling/fatpacking. Be it an argument to Makefile.PL/Build.PL or an environment variable.
cpanm since 1.5something stores the configured MYMETA files as well as its own install.json file, which contains how the module was retrieved etc. in the .meta directory inside auto/arch. This is a useful replacement for .packlist files, but the file location and format should better be formalized and supported by build tools.
Some CPAN modules install other CPAN modules, and run cpan installer from inside their own code to do so. Popular examples include dzil install, lib::xi or CloudPAN. Usually they have their own decision of which installers to use out of CPAN.pm, CPANPLUS of cpanm and hardcodes it inside their code. Wouldn't it be nice if a user can express their preferred installer somehow, and let there be CPAN::Any that use one of those with the transparent interface? Prototype available at miyagawa/CPAN-Any
There are many tests in the wild that waits for an input in tests. Because cpanm hides the output in non-interactive mode, users will see no chance giving inputs to such tests. It used to set AUTOMATED_TESTING variable to 1, which makes many of these tests to not wait for input, but that triggers other set of tests, which are known to be slow and CPU excessive (i.e. meant to be run only on CPAN Testers).
Some other modules mistakenly use PERL_MM_USE_DEFAULT in testing. It would be nice if there's a consensus to use which (old or new) flag to indicate that the test is interactive, but yet doesn't want CPAN Testers slow tests. I'm ok with repurposing AUTOMATED_TESTING for that, and introduce a new variable for smoking CI tests for CPAN Testers / Jenkins / Travis CI. Whichever works.
cpanm 1.6 has added install from git URL. There's also some times when you want to build or test a CPAN module from git (i.e. Travis CI). The problem is that if you use a build automated tool such as Dist::Zilla or Module::Install, often by default the build will fail since there's no standard Makefile.PL or Build.PL, or missing inc/ directory for Module::Install etc.
Travis CI allows specifying the hooks in .travis.yml so that's no brainer, but I'd like to see how that can be generalized if applied to cpanm git://... usage. Personally I created a dist.ini that copies META.json and Build.PL (using Module::Build::Tiny) back to the git repository for each release, so that it can be built from git repository without dzil as well. Would like to share some thoughts on the best practice.
One reasonable step cpanm can take is to intall develop requirements before configuration (in addition to configure requirements) when it detects the git-like development environment, rather than from PAUSE.
There should be an option to install recommends/suggests prereqs in cpanm, the only difference is that it will proceed upon failures to install these dependencies.
Need to figure out how to describe OS/perl specific dependencies in cpanfile (without using obvious if ($^O eq "..."))
aka Travis Testers
02packages can only have the latest version indexed. Would be nice if a CPAN/darkpan mirror can have one index file with all the history of module+version, rather than just the latest, so the cpanm 1.6's version query will work with CPAN mirrors as well, not just via MetaCPAN queries.