Front page | perl.perl5.porters |
Postings from February 2017
On Tue, Feb 14, 2017 at 9:10 PM, Todd Rinaldo via RT <perlbug-followup@perl.org> wrote: > Yes I'm learning this the hard way. I'm sure that process has been exhausting to you :-/. > Is there any interest in changing > this? Given the priorities put on the toolchain to maintain stability > among other things. It's surprising to me there is no good forum > to have a discussion more frequently than once a year. I can't think of any case where the stars aligned quite like they did here. I don't think optimizing for once per decade events is fruitful. > Given we're talking about ~3,700 dists on CPAN that would need to > be patched and re-released, I have no expectation this is ever going > to be fully solved. I could see some day deciding that the remaining > 500 modules are unused or sufficiently broken that breaking their > installer isn't the end of the world at which point we could take it > out. It affects a lot of distributions, but fairly few users (installing manually is already a painful experience in all but the simplest cases). > > * What are the consequences of this inc::Module::Install being different > > from the CPAN one? What if they converged? > > This module is more a shim with re-produces what the installed > Module::Install module already does. With the exception of the > HIGHLY unlikely event that someone starts actively developing > on M::I, I don't think there's any particular risk of divergence. What if this shim was a CPAN distribution? Ironically but conveniently the error message already literally says «you may need to install the inc::Module::Install module», what if listening to what perl is already telling you would solve the problem? It's the same error that manual users would also get for anything using configure-requires (e.g. anything using Module::Build::Tiny); installing it once would permanently solve this issue for this userbase. An important advantage is that this would actually allow for the shim to be updated if necessary; core and CPAN's inc::Module::Install being divergent would mean we can't update it, which is a major risk factor. The main practical complication in this is that inc::Module::Install already exists as part of Module::Install. It actually does something similar, but has rather different aims (targeting the author). I suspect this ultimately won't be a major complication though. And even if we would put it into core after releasing it to CPAN, this would provide a credible exit-strategy once it's time to eject it. LeonThread Previous | Thread Next