Front page | perl.perl5.porters |
Postings from June 2020
Re: Announcing Perl 7
From: Dan Book
June 30, 2020 06:40
Re: Announcing Perl 7
Message ID: CABMkAVVVcibp=zMhR3MyZF3YmHBikpq+cwmC4m=e6FZtvrTYKg@mail.gmail.com
On Tue, Jun 30, 2020 at 2:00 AM Darren Duncan <firstname.lastname@example.org>
> On 2020-06-29 10:40 p.m., Tom Molesworth wrote:
> > On Tue, 30 Jun 2020 at 13:33, Darren Duncan wrote:
> > On 2020-06-29 10:22 p.m., Tom Molesworth via perl5-porters wrote:
> > > So one concern that does not seem to have been addressed by the
> "enable by
> > > default" proposal is "what about CPAN". It used to be a selling
> point for
> > Perl,
> > > would be a shame to lose that.
> > Well I DID say that CPAN is one of those places where explicit
> versions SHOULD
> > be used. And if any don't, well CPAN is public, and as you
> demonstrated we can
> > see what would break. And so we now are in the position to fix
> those modules.
> > Fix... how? They aren't broken until we change the rules, some of them
> > had a release in years, and are you suggesting that p5p takes
> responsibility for
> > unilaterally releasing patched versions? Ignoring licenses and any other
> > concerns, seems like a lot of work - and that hasn't even happened in
> the past
> > for dual-life modules, look at the cases where *core Perl* releases with
> > "development versions" of important modules because there's a patch that
> is not
> > yet on CPAN. Have a look at the Scalar-List-Utils sorting discussion
> from not
> > too long ago - even when there's a working patch, it's not always
> trivial to
> > ensure that it makes it into a stable release.
> > With limited available resources, and a long list of things to be done -
> many of
> > which are the subject of separate threads which haven't even started yet
> - it
> > would seem safer to avoid a big "release all the modules" project. Maybe
> > more advanced patching option is something that the toolchain is already
> > on...
> Fix means make compatible. And the argument is for the community at large
> to do
> it, not just those who maintain the Perl interpreter.
> I recall various comments that the Perl 7 announcement has lit a fire
> under the
> wider Perl community and a lot of people are chomping at the bit to help
> effort. Well providing compatibility updates to modules is a good use of
> Lots of modules are in public version control and people wanting to help
> submit pull requests for them. This has happened over the years anyway.
> A low-hanging fruit is that if anything doesn't work with use strict it is
> updated to declare its variables and so on.
> Personally I do NOT advocate that signatures or anything likely to change
> turned on by default, but simpler things unlikely to change should be like
I am just going to say, I think you have not been paying attention to many
of the attempts to do things just like this on CPAN previously if you think
this is attainable, nevermind easy. We are still trying to get rid of
problematic uses of Module::Install to this day.