Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re: p5p vs CPAN

by Corion (Pope)
on Oct 17, 2019 at 08:07 UTC ( #11107585=note: print w/replies, xml ) Need Help??


in reply to p5p vs CPAN

The slow painful drip of backward incompatible changes only affects you if you upgrade. And I would say that the minor (but breaking) changes are mostly minor changes, but we feel them as nasty because we (as a part of the community) have the expectation that our scripts from back then (be it Perl 4, or Perl 5.005_03 or Perl 5.12) still work unchanged.

I also don't see it as "p5p vs CPAN", because I would say that all participants on perl5-porters deeply care about keeping (modules on) CPAN working well and work with module authors to keep the breakage introduced through changes low. Bugward compatibility takes a backseat to correctness for example.

But looking at it from a different perspective, it is great how much of it still works after 20 years of changes. So it's not all doom and gloom in my opinion.

There are many ways to publish your patches instead of keeping them locally. In ascending order of utility (but also, descending order of ease, unfortunately):

  1. Publish the changed repository on Github or wherever. This has the advantage of not even needing a CPAN account. The disadvantage is obviously that nobody will find your patches.
  2. Publish the patch as a CPAN::Distropref in your own CPAN directory. This has the advantage of getting the patch applied automatically whenever you (re)install the distribution. The disadvantage is still that nobody will find your patch and the reasons for why you made it. But at least they can install a module that will find them.
  3. Open a ticket on the issue tracker for the module and attach the patch there. This has the benefit that others who encounter the problem will see the problem, and they can apply your patch locally. Also, I've often (re)found my patches in tickets when (re)installing a fresh Perl version. Maybe the author wakes up and incorporates your patch into a fresh release.
  4. If the author is unresponsive, work with the author and modules@perl.org to adopt the module or get co-maintainership. Then, incorporate your changes and release a new version. I'm currently in the process of doing that with Spreadsheet::ReadSXC. This is a slow process as everybody involved has other priorities and you should look at this in a timeline between 3 months to years until progress happens. The upside is that once you are the new maintainer, you can put out the new release with your fixes and maybe the accumulated fixes from the bug tracker (or forks) as well. Ideally you also add other people as co-maintainers on CPAN so that you don't become the next single point of failure.

Update: Fixed description of how the list was sorted.

Replies are listed 'Best First'.
Re^2: p5p vs CPAN
by tobyink (Canon) on Oct 17, 2019 at 12:02 UTC

    I also don't see it as "p5p vs CPAN", because I would say that all participants on perl5-porters deeply care about keeping (modules on) CPAN working well and work with module authors to keep the breakage introduced through changes low. Bugward compatibility takes a backseat to correctness for example.

    I agree; they're pretty rigorous at investigating how changes affect CPAN modules. That doesn't mean they won't make the changes anyway, if they're overall beneficial, but they seem to avoid module breakage pretty well.

    An optimization for how constants were put into the stash in one of the 5.27.x broke the Type::Tiny test suite (and also Role::Tiny and Variable::Magic, I believe). They backed it out and worked with module authors, providing patches and additional test cases, before rolling it back into the 5.27.x code ahead of the stable 5.28.0 release.

Re^2: p5p vs CPAN
by Anonymous Monk on Oct 17, 2019 at 12:40 UTC
    > Bugward compatibility takes a backseat to correctness for example.

    This is the problem. The perfect (p5p) is the enemy of the good (CPAN). How can it be acceptable that "fixing" Perl is "breaking" CPAN? I noticed the breaking changes tend to reduce the DWIM nature of perl in favor of some abstract notion of what is correct, like for example, my $foo qw(bar baz) makes perfect sense and was valid perl until some programming justice warriors decided that breaking backcompat was less important than their idea of programming correctness.

    The result is broken scientific distros sitting on CPAN forever because, for example, we now have to --force install and add 2 characters to 1 module to fix 3 modules. Someone who is more of a scientist than a perl programmer will shrug their shoulders and move on to a programming language with working libraries. It's a dire situation!

    Thank you Corion and daxim for your thoughtful replies and valuable information (but that anonymous reply, get an account! =)

      like for example, my $foo qw(bar baz) makes perfect sense and was valid perl until

      I'm afraid to say that it doesn't make perfect sense to me. What would you expect it to mean?

      It's also not valid perl, even on the oldest one I could find:

      $ perl -v This is perl, v5.8.8 built for i386-linux-thread-multi Copyright 1987-2006, Larry Wall Perl may be copied only under the terms of either the Artistic License + or the GNU General Public License, which may be found in the Perl 5 source ki +t. Complete documentation for Perl, including FAQ lists, should be found +on this system using "man perl" or "perldoc perl". If you have access to + the Internet, point your browser at http://www.perl.org/, the Perl Home Pa +ge. $ perl -e 'my $foo qw(bar baz)' syntax error at -e line 1, near "$foo qw(bar baz)" Execution of -e aborted due to compilation errors.
      The result is broken scientific distros sitting on CPAN forever because, for example, we now have to --force install and add 2 characters to 1 module to fix 3 modules.

      I am no advocate for breaking backwards compatibility but a seemingly trivial change to a module which moves it from unusable to working on modern perls is something any module maintainer should be doing. Just not necessarily in the next half hour. If there's no repsonse to such tickets in a reasonable time-frame (give them a few weeks at least) then it's probably abandoned and a good candidate for a take-over.

        like for example, my $foo qw(bar baz) makes perfect sense and was valid perl until
        I'm afraid to say that it doesn't make perfect sense to me. What would you expect it to mean? It's also not valid perl

        I assume this was the same anonymous monk from Re^2: How can I create a simple Autocad drawing with Perl, who complained about needing to fix foreach my $action qw(load save) { to foreach my $action (qw(load save)) { in order to use CAD::Drawing::IO. Apparently, this AM either didn't read, didn't like, or didn't accept afoken's detailed explanation as to why the original syntax was never meant to work (hence Corion's use of "bugwards compatibility" earlier in this thread).

        It's also not valid perl, even on the oldest one I could find ... v5.8.8

        According to CPAN Testers "Use of qw(...) as parentheses" was "valid" perl after 5.8.8. The deprecation warning showed up in 5.13.5 and became fatal for linux in 5.18.1 and bsd in 5.18.4. Then this broke: foreach my $foo qw(bar baz){}

      In that case, it was always a bug, it just wasn't reported by Perl as such.

      If you want more "influence", consider becoming a part of p5p. It's as easy as reading the mailing list and/or writing a mail to it:

      Please note that these are all volunteers, so taking a belligerent stance may not get your case heard in the way you want. But if you are interested in actually fixing the problems, I'm sure you will be welcome there.

        taking a belligerent stance may not get your case heard

        I'm not really that belligerent, just trying to be funny about a tragic subject, with a somewhat frustrated rant. Sorry if my sense of humor offends anyone. I am serious, and silly simultaneously, for pure enjoyment.

        In that case, it was always a bug, it just wasn't reported by Perl as such.

        Maybe it wasn't reported as a bug because it was a feature? I'm curious how "fixing" that particular "bug" really improved Perl? Does it 1) make new things possible, or 2) make things that should have worked function properly, or does it just remove one of a million shortcuts and 3) break the holy grail: CPAN? (I understand what is "wrong" with for qw(), but don't care! DWIM)

        if you are interested in actually fixing the problems

        My preferences in order:

        1. Someone never decided to cause this problem.
        2. Someone with more power and skill fixes the problem.
           a. Repair Perl backwards compatability.
           b. Repair CPAN distributions.
        3. I fix the problem locally and am happy that it works.
        4. I have to work to fix the problem for everyone.
        
        I know you want me to do 4 because of 3 but I'm looking at 1 with an occasional glance at 2a =)

      Could you list some of the broken distros? There might be simple fixes that others could implement.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11107585]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2019-12-14 13:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?