develooper Front page | perl.perl5.porters | Postings from February 2017

Re: [perl #130467] Default perl builds to not include . in @INC(default_inc_excludes_dot)

Thread Previous | Thread Next
Leon Timmermans
February 16, 2017 00:09
Re: [perl #130467] Default perl builds to not include . in @INC(default_inc_excludes_dot)
Message ID:
On Tue, Feb 14, 2017 at 9:10 PM, Todd Rinaldo via RT
<> 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

> > * 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.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About