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
From:
Kent Fredric
Date:
February 13, 2017 14:26
Subject:
Re: [perl #130467] Default perl builds to not include . in @INC(default_inc_excludes_dot)
Message ID:
CAATnKFC=BKtoi52twK-jFwR8dYAB5Ldgh25JjMiHsv5YTChmQg@mail.gmail.com
On 14 February 2017 at 00:33, Sawyer X <xsawyerx@gmail.com> wrote:
> Importantly enough, Kent's position is not "We need a bit more time on
> this". His position, as stated in another email, is to make this change
> at a "glacial" speed (quoting Kent), which means that no amount of
> discussion that results in less than at least 2 additional releases for
> this would be considered "enough time". This is besides my point
> entirely and I have no intention of continuing such a conversation.
To clarify: I don't have a fixed position, and that suggestion was
just that: A suggestion.
Its simply an example of the sort of thing that *could* be done if we
simply changed what our priorities are.
It was in my mind, an ideal, a feasible strategy for the least amount
of breakage and giving affected people the most amount of time to
adapt.
The inc:: approach here stands on a line between "lots of breakage"
and "slightly less than lots of breakage"
There may be strategies somewhere on that line between the inc::
approach and the more glacial warn/die split phasing.
Just the perception given is that the inc:: approach is "settled" now,
and that we're jumping at the approach without adequate pause.
And the pressure to create such a settlement is placed upon us by the
looming feature freeze, and I'm afraid we're going to hit
yet-another-last-minute-rush where contentious features land without
proper prepartation late in the cycle.
I'd we'd tackled this problem earlier in the development cycle, we'd
not be having this sensation of approaching panic.
We can't change that now, no time machine.
But using the "we have to because time" is something that is almost
guaranteed to force our hand in the direction of the worse choices.
I know you see me as "negative", and read me like I'm just nay-saying
everything, but there's so much more to it than that.
My point is usually to establish that there *are* other points on the
line, and maybe there are satisfactory points between existing points
that satisfies everyones concerns.
But that you see me myself as trying to establish a "this is how it
will be" is making you make counter-active assertions to the same
effect, much to my frustration, and probably to yours.
For the record, I have no direct opposition to inc::Module::Install
hiding in @INC as per todds suggestions. The only problem I have is it
that its *not enough*, and leaves quite a few problem cases unsolved.
Those problem cases *could* in theory be fixed by submitting patches to CPAN.
The problem is there's no way to smoke and fix code outside CPAN, and
CPAN thus represents the very tip of this problem, not the problem
itself.
Hence, it is important to me that we at least properly explore options
in that direction, and we rather haven't to my understanding, hence
the frustration with it being described using that word ( it had a
quick-acting and visceral effect )
But for an example of something that I *might* reluctantly not oppose
( but please, don't hold me to it )
Some sort of mechanic that simply gives a better error message when
".pm file found in . but we're not gonna load it" happens, so at least
when things do barf unexpectedly, its not a complete confusion.
Or perhaps we can ascertain there are classes of "Less volatile" entry
points ( for instance, when the top level __FILE__ is =~ /.PL/ ) where
different behaviour may take place.
--
Kent
KENTNL - https://metacpan.org/author/KENTNL
Thread Previous