develooper Front page | perl.perl5.porters | Postings from August 2016

Re: Alternative Fix for base.pm dot-in-INC mechanic.

Thread Previous | Thread Next
From:
Kent Fredric
Date:
August 24, 2016 14:18
Subject:
Re: Alternative Fix for base.pm dot-in-INC mechanic.
Message ID:
CAATnKFAz1z7H7dMAyW0_5Ey8cR0kH76sqS1tXP0YGsyJAmTW7A@mail.gmail.com
On 24 August 2016 at 22:59, Todd Rinaldo <toddr@cpanel.net> wrote:
> The changes being made to base.pm seem to have proven to have a high risk of being an API change. This kinda makes it inappropriate for a maintenance release. Assuming we have an alternative plan for 5.24 and forward, I recommend we simply hi-light the risk of using base and NOT fix it.
>
> IMO, There's nothing wrong with saying "there's a risk here" and leaving it to other's to assess and mitigate the risk in their own way on legacy Perl.

I'm in agreeance.

And I also agree the "right place" to fix ". in @INC with base.pm" is
in the code that uses base.pm, not inside base.pm itself.

base.pm ( and anything else that loads user defined modules passed in
as strings literally ) are essentially "proxies for require", and
should be treated as such to avoid introducing breakage in a stable
point-release.

And as such, we should fix things that /use/ base.pm (and friends) to
avoid *them* being a security risk.

But changing the semantics of require and require proxies should
happen together, and happen properly when we work out how to do that
in a Major Release and work out all the kinks in whatever
implementation details we decide on.

After all, upgrades between stable point releases should be
predictable *improvements*, not predictable regressions.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About