develooper Front page | perl.perl5.porters | Postings from June 2020

Perl 7 and CPAN (was: Re: Announcing Perl 7)

Sam Kington
June 27, 2020 00:25
Perl 7 and CPAN (was: Re: Announcing Perl 7)
Message ID:
On 26 Jun 2020, at 20:59, Sawyer X <> wrote:
> We have
> indeed thought *a lot* about not breaking CPAN. It's difficult and we
> won't cover 100% (nor should we) but we did come up with mitigating
> factors which should suffice for a fair portion, giving users a
> seamless experience.
> We will work on sharing this soon in greater detail.
> I apologize for not expanding enough on this since it does strike all
> of us as an immediate major risk to this plan.

My apologies if any of this was mentioned in the keynote, which I still haven’t got around to watching; I don’t have a commute, and I really dislike watching videos of someone talking if I could instead read a transcript.

Nonetheless, I really do think that if you were going to announce Perl 7, you should have prepared FAQs, Apocalypses, PEPs, whatever, so people didn’t have to guess at what this all meant. Saying to geeks zeroing in on their particular area of expertise “wait a while, we’re going to get something up about that soon” is terrible timing.

To take a comment from elsethread:

> 1. People do not actually use "use v". This is what we've seen with it
> so far. CPAN is an example, and every code-base I touched and
> discussed with peers had rarely used it. It is true that this is
> anecdotal because I haven't touched or discussed every code-base, but
> I am in touch with a few major Perl shops. It is rarely used by any of
> them. This has to account for a fair portion of active Perl code and
> this anecdote does means something. We have a mechanism we believe is
> superior and gives our users what we think we want. Our users don't
> use it. Aergo, our mechanism isn't the gift to developers we thought
> it is.

We don’t say “use v” in our codebase at work; we say “use our::way” and the private module our::way imports the various pragmata we like. We similarly have a perltidyrc and a perlcriticrc that match how we want to write code. These are never going to end up on the CPAN because, frankly, who’s interested?

When I write CPAN modules, I aim for maximum backcompat, and so I don’t use subroutine signatures - even if I really want to! - because on the off-chance that someone might find my code useful, I don’t want to say “sorry, kid, your perl is too old”. I say use strict, use warnings, and frankly most of the time that’s good enough.

How does perl 7 reconcile these two demands: using the most recent Perl you know you have available to you, but supporting as many older Perls as you can?

Because as soon as I start writing Perl code with subroutine signatures for the CPAN, I either have to say “sorry, guys, but your Perl is too old”, or fork the code.

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