I applaud the fact that module installation is becoming a more granular and customizable process. But absolutely not at the expense of reversing the trend in the past few years to eliminating interaction.
Today I got several "Module X is required temporarily during installation, but do you want to install it permanently?" questions while trying to update from CPAN. This is absolutely wrong. Any system advanced enough to recognize the difference between modules required for build and modules required at runtime is advanced enough to have been written by someone advanced enough to know that this is absolutely wrong and archaic.
if ( !-t STDIN ) {
$do_not_prompt = 1;
$do_not_install_permanently = 1;
}
Or something like that. You would think we toolchain developers would get tired of people yelling at us
Re:build_requires_install_policy
jdavidb on 2008-11-11T15:35:47
How about the owner of that module defaults it for me, instead?
Re:build_requires_install_policy
srezic on 2008-11-11T19:55:33
How should the module author know what your installation policy is --- do you prefer to keep your system as small as possible by not installing unnecessary modules (see build_requires in the META.yml spec), or do you rather like to install everything?Re:build_requires_install_policy
jdavidb on 2008-11-13T14:39:25
The authors of the installation framework should know that interactive questions should not be asked at install time.
Re:build_requires_install_policy
srezic on 2008-11-13T20:09:52
See this thread title. You can set this CPAN.pm config var to "yes" or "no", and you will never be asked. Currently it's probably "yes/ask" or "no/ask".
Re:OTOH....
bart on 2008-11-09T12:07:51
I've been thinking a bit about this, and I'm wondering if it wouldn't be a good idea to have a middle ground: semi-permanently installed modules, or a more permanent CPAN cache, one that isn't emptied so often when CPAN.pm tries to save space by removing distributions from its cache. CPAN.pm could automatically store modules there that are only required to run tests, without asking. The more often a module is used, the more "sticky" it becomes, thus, less likely to be removed. A module that hasn't been used in months could be removed.
