|
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.
| [reply] |
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! =) | [reply] |
|
|
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. | [reply]
[d/l] |
|
|
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).
| [reply]
[d/l]
[select] |
|
|
| [reply] |
|
|
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.
| [reply] |
|
|
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.
| [reply] |
|
|
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 =) | [reply] |
|
|
|
|
| [reply] |