On 2017-04-22 02:16:56, DJERIUS wrote:
>
> I rarely rant in public, but I'm going to make an exception
> here. I'm rather frustrated with the situation and the tone of
> the response that I'm getting.
>
> Let me lay this out in another fashion.
>
> I'm a CPAN author.
>
> I download the latest development version of Perl, make sure I'm
> in a clean environment, fix the code so that it works.
>
> Now I'm informed, not by p5p, nor anyone working on the
> toolchain, but via a bug report from a tester, that there's a
> special environment variable that now has to be set to pass CPAN
> tests.
Hi. It may have been me, or one of the other 4 people I saw filing bugs, that reported this, so if it was me, I apologize for lack of clarity.
But it should stand that the reason for filing that bug was that I was taking this problem seriously, and taking it upon myself to at least inform authors in some manner that a future Perl release will, in some future, break your code in some way.
Thus, maybe it wasn't clear, but I am intending to work in some capacity as a toolchain worker :)
Sadly, there is just too many of these problems, >20% of CPAN is broken under this condition.
I've practically spent every free minute of my life for the last 2 months ( and that is far from an exaggeration ) simply hunting down and reporting distributions that are affected, in the hope that there will be at least *some* indicator of this problem before it starts affecting people.
So believe me when I say "This is an unprecedented situation"
This is incredibly problematic and difficult, and the change, though long planned, was activated and deployed very last minute, and there's subsequently a mad rush to mitigate the fallout.
> A non-standard, poorly documented variable at that. There's
> nothing in the release notes which indicates that
> PERL_USE_UNSAFE_INC=0 is special, only that setting it to 1 has a
> particular effect. Any reasonable person would assume that
> setting it to 0 would be the same as not setting it, but that's
> obviously not the case.
Indeed, and agreed. And such documentation is planned ... but I still can't find it anywhere. Rumour has it it might land in the 5.26 release notes.
But its only existed since 5.25.10!
But the point is *not* that end users should be setting it.
The point is a significant and long relied upon mechanic in Perl has become broken By Design, and P5P have provided a *temporary hack* to counter-act the reality that lots of this code ( See aforementioned lack of precedent ) is broken by this change.
P5P could have opted never to produce said variable, and we'd just be in the same sticky mess we're in now, but it would be more dire, because affected code would not only be broken for people using non-CPAN tooling like me, not just for maintainers and hand-installations, but for _everyone_ on CPAN.
And there are so many ADAMK dists that would be broken, its just not realistic to have no-workaround :/
> It may be fair for the testers to set that variable, but it's
> blatantly *unfair* to CPAN authors not to inform them of this new
> requirement. There has been no communications from p5p or the
> toolchain maintainers to CPAN authors. You do have our email
> addresses!
>
> A simple email would suffice to clear everything up. We aren't
> privy to what's going on in the innards.
>
> Give developers clear guidance on what to do. Make it public!
>
> Don't make us read through the code or pore through release notes
> for umpteen things to figure out why special environment
> variables work or don't work.
>
> And please, don't tell me what the "proper" response as a
> developer is. That's patronizing and offensive. I wouldn't have
> started this conversation if I didn't already take my
> responsibility seriously.
In reality, there's so much confusion here, and I don't blame you really. I've seen ex-pumpkings and many other people who could be imagined they *should* know better mess this up.
In reality, even though this variable is created ( and instituted in tooling ) as a stop-gap to protect end users from catastrophe, its very existence and the mechanisms we use to protect users act as a direct disservice to CPAN authors, because its nature and prevalence is simply that *having it set* hides *real bugs*
Consequently, there's been a raft of "I reported this dist failed" and people applying fixes and releasing them ... only to find they didn't fix the issue, because their tools hid the failures from them. That's great for end users, but for maintainers, that's just giving them a false sense of security which will collapse in one way or another ( either immediately after installation, or 2 years from now )
I really wish we'd found an approach that made sense where only users were protected, but authors still got the horror shows of breakage ... but . Well, nobody managed to figure out how yet.
Yes, this is all horrible, and the nightmare is long from over for me :/
What you should do?
You want your code to work with that flag in either condition, you should assume it won't be there one day, and forcibly turn it off to simulate how it will eventually be [ or in some cases, will be outside `cpanm` and friends ]
Think of the flag as being called PERL_BE_524_COMPATIBLE=1
With the flag on in 5.25.11, you're seeing Perl how it behaves on perls before 5.25
With the flag off in 5.25.11, you're seeing how Perl is designed to work "now"
End users shouldn't care about the flag, because its not really an end users job to fix CPAN modules that no longer work on newer perls, but end users have that flag as a defence because CPAN is a huge unmaintained wasteland sometimes.
Again, sorry for the lack of clarity, everything here is awful
Additionally, hopefully the draft documentation here is useful, and if not, please ask for clarification/corrections, because I'd hate for our final documentation in 5.26 to also be useless.
http://www.nntp.perl.org/group/perl.perl5.porters/2017/04/msg243878.html
I do think this situation is significant enough that every CPAN author needs to know about it, but how do we achieve that?
We may have *your* email on file, I assume your @CPAN address works, but how do we deal with the large numbers of @CPAN addresses that now just end up bouncing?
There were numerous blogs about this on blogs.perl.org , they got referenced on reddit, its been a daily conversation on IRC. ( http://blogs.perl.org/users/ryan_voots/2017/04/trials-and-troubles-with-changing-inc.html )
What other channels are there to explore to ensure people who need to know know?
Would social networks help?
--
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )
