Add static install support

[Leont]

This is a first stab at implementing static installation.

It's not tested at all yet, nor is it complete (especially around logging and reporting), but it should in essence get the job done.

[briandfoy]

Taking out the Mac classic stuff might be better as a separate PR. But, oh, it is #82 and snuck into this PR. :)

[Leont]

Taking out the Mac classic stuff might be better as a separate PR. But, oh, it is #82 and snuck into this PR. :)

Yeah taking it apart causes conflicts, but #182 should be a no-brainer.

[andk]

Thanks @Leont, I have taken your PR into my branch https://github.com/andk/cpanpm/tree/pr-183-contd and have continued on top of it.

Outstanding issues:

• needs support for CPAN::Reporter
• needs integration with code dealing with unsatisfiable prerequisites
• maybe you know more open issues?

I could make this a TRIAL release if this is considered helpful. My testing seems to show that this branch is working well as long as the configuration turns static install support off (use_static_install => 0).

[andk]

@Leont or who it may concern : there was a bit of progress in my branch pr-183-contd , current commit is 2.38-28-g5cd61c4e ; but now I'm stuck and would be glad to get feedback. The last commit is just a sketch and does not work when there is no Build.PL and maybe under other circumstances. For CPAN::Reporter to work we need a commandline that gets passed to CPAN::Reporter::test(), which then runs the tests. Any suggestions?

BTW, the first report generated with that commit was: https://www.cpantesters.org/cpan/report/5b3bcb52-8317-11f0-bcfe-8752473a1684 about DBIx-Class-EncodedColumn-0.11

[Leont]

The last commit is just a sketch and does not work when there is no Build.PL and maybe under other circumstances.

The spec says that there should always be a Build.PL or Makefile.PL to fall back on, so that isn't necessarily a disaster. If we can't make static install work with CPAN::Reporter (but I think we can), we should just disable it if CPAN::Reporter is turned on.

For CPAN::Reporter to work we need a commandline that gets passed to CPAN::Reporter::test(),

CPAN::Static comes with a command-line tool: cpan-static. cpan-static test should DWIM, and should respect all the usual test harness environmental variables.

[andk]

@Leont : cpan-static does not seem to get installed per default. Should I write an issue to CPAN-Static-Install or do you have a better idea anyway?

[Leont]

cpan-static does not seem to get installed per default. Should I write an issue to CPAN-Static-Install or do you have a better idea anyway?

I can't reproduce that.

Installing /home/leont/perl5/perlbrew/perls/perl-5.42.0/man/man1/cpan-static.1
Installing /home/leont/perl5/perlbrew/perls/perl-5.42.0/lib/site_perl/5.42.0/CPAN/Static.pm
Installing /home/leont/perl5/perlbrew/perls/perl-5.42.0/lib/site_perl/5.42.0/CPAN/Static/Spec.pm
Installing /home/leont/perl5/perlbrew/perls/perl-5.42.0/lib/site_perl/5.42.0/CPAN/Static/Install.pm
Installing /home/leont/perl5/perlbrew/perls/perl-5.42.0/man/man3/CPAN::Static::Install.3
Installing /home/leont/perl5/perlbrew/perls/perl-5.42.0/man/man3/CPAN::Static::Spec.3
Installing /home/leont/perl5/perlbrew/perls/perl-5.42.0/man/man3/CPAN::Static.3
Installing /home/leont/perl5/perlbrew/perls/perl-5.42.0/bin/cpan-static

[andk]

OMG, my bad, sorry.

[andk]

@Leont : now I think I have a case that calls for a defense directly in supports_static_install. Consider a META.json that has both
'dynamic_config' => '1', and 'x_static_install' => '1'.

In such a case supports_static_install() should most probably never return true; but currently it does.
What do you think?

Case in question: https://metacpan.org/release/CXW/List-AutoNumbered-0.000010/source/META.json

[andk]

@Leont , just FYI: in my latest commit 2.38-35-ged0daea8 I have implemented the defense I originally considered a good fit for supports_static_install(); so I feel safer now with my current implementation and I'm testing it in two fullsmoker VMs over the next weeks.

[Leont]

Consider a META.json that has both
'dynamic_config' => '1', and 'x_static_install' => '1'.

In such a case supports_static_install() should most probably never return true; but currently it does.
What do you think?

It shouldn't happen, but Murphy's law applies so it probably will at some point. Any author doing that is silly, and rejecting that seems reasonable.