Skip Menu |

This queue is for tickets about the Sub-Identify CPAN distribution.

Report information
The Basics
Id: 98753
Status: resolved
Priority: 0/
Queue: Sub-Identify

People
Owner: RGARCIA [...] cpan.org
Requestors: dolmen [...] cpan.org
Cc: ribasushi [...] leporine.io
AdminCc:

Bug Information
Severity: Critical
Broken in: (no value)
Fixed in: 0.08



Subject: 0.05 requires perl 5.14.1, breaking compatibility
0.05 breaks compatibility with older perls without warning:
- not even a major version number change
- no documented migration path for perl < 5.14.1 users

-- 
Olivier Mengué - http://perlresume.org/DOLMEN - https://gratipay.com/dolmen/
On Wed Sep 10 05:16:31 2014, DOLMEN wrote: Show quoted text
> 0.05 breaks compatibility with older perls without warning: > - not even a major version number change > - no documented migration path for perl < 5.14.1 users
Indeed test files 20 and 21 rely on a bugfix available on 5.14.1 or later. Moreover CvPROTO new in 0.05 is not available on ancient perls, although the pure perl version will work. Sorry then, the module just does not work on ancient perls, hence the version requirement.
The workaround is probably to use Sub::Util::subname.
https://metacpan.org/pod/Sub::Util#subname

This should be documented.

-- 
Olivier Mengué - http://perlresume.org/DOLMEN - https://gratipay.com/dolmen/
On Wed Sep 10 05:32:07 2014, DOLMEN wrote: Show quoted text
> The workaround is probably to use Sub::Util::subname. > https://metacpan.org/pod/Sub::Util#subname > > This should be documented.
Sub::Util and Sub::Name are now in SEE ALSO, and I believe they'll crash likewise on subs being compiled.
Le 2014-09-10 11:48:59, RGARCIA a écrit :
Show quoted text
> Sub::Util and Sub::Name are now in SEE ALSO, and I believe they'll
> crash likewise on subs being compiled.

It looks like I do not fully understand.
Do you mean that no workaround is possible?
If the issue is a particular kind of subs, is it not possible to detect it and fail in that case on old perls?

In any case, we need more gory details in the POD.

-- 
Olivier Mengué - http://perlresume.org/DOLMEN - https://gratipay.com/dolmen/
On Wed Sep 10 11:28:05 2014, RGARCIA wrote: Show quoted text
> > Sorry then, the module just does not work on ancient perls, hence the > version requirement.
This is not true. There are two things that make the version bump unacceptable: 1) The XS portion requires newer macros yes, but nothing prevents you from having a couple of IFDEF's. Moreover extra PPPort application is likely to make the problem go away altogether 2) (much more importantly) The module always had a pure-perl implmentation which works all the way back to what *I* consider ancient. If you are not interested in doing the work required for (1), which is entirely your right, you must modify your builder to skip building XS on < 5.14. This way you get the C code in whatever shape you prefer, and yet nobody gets broken deployments. Please consider rectifying the situation sooner rather than later. I could provide a patch for (2) but didn't want to do the legwork in case you reconsider and do the proper fix of (1). Thank you
The pure perl version will crash as well on the attribute tests. I have no RT reference, but the bug was originally reported on http://www.fukurama.org/wordpress/2007/11/20/modul-zum-auflosen-von-methodennamen/ and then on P5P. I suppose I could re-mark this test as SKIP TODO on ancient perls. Your suggestion sounds good. Provide a patch ? :)
On Wed Sep 10 12:00:39 2014, RGARCIA wrote: Show quoted text
> The pure perl version will crash as well on the attribute tests. > I have no RT reference, but the bug was originally reported on > http://www.fukurama.org/wordpress/2007/11/20/modul-zum-auflosen-von- > methodennamen/ and then on P5P. > > I suppose I could re-mark this test as SKIP TODO on ancient perls. > Your suggestion sounds good. Provide a patch ? :)
There is one more issue I was made aware of - https://rt.cpan.org/Ticket/Display.html?id=93296. If you are given a set of patches doing clean separation of the entire thing - will you be willing to work them in? There is prior art - we split Devel::GlobalDestruction the same way about 2 years ago with 0 fallout.
On Wed Sep 10 06:03:46 2014, RIBASUSHI wrote: Show quoted text
> There is one more issue I was made aware of - > https://rt.cpan.org/Ticket/Display.html?id=93296. If you are given a > set of patches doing clean separation of the entire thing - will you > be willing to work them in? > > There is prior art - we split Devel::GlobalDestruction the same way > about 2 years ago with 0 fallout.
I don't think that splitting XS code in a separated distribution is a good idea (unless the pure-perl distribution requires the XS one, which renders the whole separation moot.) I'd rather move the pure-perl code into a ::PP module.
Subject: Re: [rt.cpan.org #98753] 0.05 requires perl 5.14.1, breaking compatibility
Date: Wed, 10 Sep 2014 13:51:43 +0200
To: bug-Sub-Identify [...] rt.cpan.org
From: Peter Rabbitson <ribasushi [...] cpan.org>
On 09/10/2014 01:47 PM, Rafaël Garcia-Suarez via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=98753 > > > On Wed Sep 10 06:03:46 2014, RIBASUSHI wrote:
>> There is one more issue I was made aware of - >> https://rt.cpan.org/Ticket/Display.html?id=93296. If you are given a >> set of patches doing clean separation of the entire thing - will you >> be willing to work them in? >> >> There is prior art - we split Devel::GlobalDestruction the same way >> about 2 years ago with 0 fallout.
> I don't think that splitting XS code in a separated distribution is a good idea > (unless the pure-perl distribution requires the XS one, which renders the > whole separation moot.) I'd rather move the pure-perl code into a ::PP > module.
The ::XS dist is required in practice. Observe: https://metacpan.org/source/HAARG/Devel-GlobalDestruction-0.13/Makefile.PL#L39 https://metacpan.org/source/RIBASUSHI/Class-Accessor-Grouped-0.10010/Makefile.PL#L24 https://metacpan.org/source/ETHER/B-Hooks-EndOfScope-0.13/Makefile.PL#L21 This is not a new problem, nor it is unusual. This is where the toolchain is moving as a whole: XS is required when the underlying environment allows it.
On Wed Sep 10 07:51:56 2014, RIBASUSHI wrote: Show quoted text
> On 09/10/2014 01:47 PM, Rafaël Garcia-Suarez via RT wrote:
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=98753 > > > > > On Wed Sep 10 06:03:46 2014, RIBASUSHI wrote:
> >> There is one more issue I was made aware of - > >> https://rt.cpan.org/Ticket/Display.html?id=93296. If you are given a > >> set of patches doing clean separation of the entire thing - will you > >> be willing to work them in? > >> > >> There is prior art - we split Devel::GlobalDestruction the same way > >> about 2 years ago with 0 fallout.
> > I don't think that splitting XS code in a separated distribution is a > > good idea > > (unless the pure-perl distribution requires the XS one, which renders > > the > > whole separation moot.) I'd rather move the pure-perl code into a > > ::PP > > module.
> The ::XS dist is required in practice. Observe: > > https://metacpan.org/source/HAARG/Devel-GlobalDestruction- > 0.13/Makefile.PL#L39 > https://metacpan.org/source/RIBASUSHI/Class-Accessor-Grouped- > 0.10010/Makefile.PL#L24 > https://metacpan.org/source/ETHER/B-Hooks-EndOfScope- > 0.13/Makefile.PL#L21 > > This is not a new problem, nor it is unusual. This is where the > toolchain is moving as a whole: XS is required when the underlying > environment allows it.
Sorry, but this approach is misguided. It's not the job of the tool chain to manage dependencies other than purely build-time dependencies. A clean separation is required for proper deployment audit and reproductibility. None of those hacks scale.
Subject: Re: [rt.cpan.org #98753] 0.05 requires perl 5.14.1, breaking compatibility
Date: Wed, 10 Sep 2014 14:01:37 +0200
To: bug-Sub-Identify [...] rt.cpan.org
From: Peter Rabbitson <ribasushi [...] cpan.org>
On 09/10/2014 01:58 PM, Rafaël Garcia-Suarez via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=98753 > > > On Wed Sep 10 07:51:56 2014, RIBASUSHI wrote:
>> On 09/10/2014 01:47 PM, Rafaël Garcia-Suarez via RT wrote:
>>> <URL: https://rt.cpan.org/Ticket/Display.html?id=98753 > >>> >>> On Wed Sep 10 06:03:46 2014, RIBASUSHI wrote:
>>>> There is one more issue I was made aware of - >>>> https://rt.cpan.org/Ticket/Display.html?id=93296. If you are given a >>>> set of patches doing clean separation of the entire thing - will you >>>> be willing to work them in? >>>> >>>> There is prior art - we split Devel::GlobalDestruction the same way >>>> about 2 years ago with 0 fallout.
>>> I don't think that splitting XS code in a separated distribution is a >>> good idea >>> (unless the pure-perl distribution requires the XS one, which renders >>> the >>> whole separation moot.) I'd rather move the pure-perl code into a >>> ::PP >>> module.
>> The ::XS dist is required in practice. Observe: >> >> https://metacpan.org/source/HAARG/Devel-GlobalDestruction- >> 0.13/Makefile.PL#L39 >> https://metacpan.org/source/RIBASUSHI/Class-Accessor-Grouped- >> 0.10010/Makefile.PL#L24 >> https://metacpan.org/source/ETHER/B-Hooks-EndOfScope- >> 0.13/Makefile.PL#L21 >> >> This is not a new problem, nor it is unusual. This is where the >> toolchain is moving as a whole: XS is required when the underlying >> environment allows it.
> Sorry, but this approach is misguided. It's not the job of the tool > chain to manage dependencies other than purely build-time > dependencies. A clean separation is required for proper deployment > audit and reproductibility. None of those hacks scale.
I completely disagree with your qualification of "hacks", and disagree with the "doesn't scale" claim - CPAN is a proof this approach does scale. Thank you for considering this and clearly outlining your position. I will start work on removing S::I from my dependency chains due to the above vision incompatibilities. A PR to fix the < 5.14 failures will be coming your way nevertheless, within a day. Cheers
On Wed Sep 10 08:02:10 2014, RIBASUSHI wrote: Show quoted text
> On 09/10/2014 01:58 PM, Rafaël Garcia-Suarez via RT wrote:
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=98753 > > > > > On Wed Sep 10 07:51:56 2014, RIBASUSHI wrote:
> >> On 09/10/2014 01:47 PM, Rafaël Garcia-Suarez via RT wrote:
> >>> <URL: https://rt.cpan.org/Ticket/Display.html?id=98753 > > >>> > >>> On Wed Sep 10 06:03:46 2014, RIBASUSHI wrote:
> >>>> There is one more issue I was made aware of - > >>>> https://rt.cpan.org/Ticket/Display.html?id=93296. If you are given a > >>>> set of patches doing clean separation of the entire thing - will you > >>>> be willing to work them in? > >>>> > >>>> There is prior art - we split Devel::GlobalDestruction the same way > >>>> about 2 years ago with 0 fallout.
> >>> I don't think that splitting XS code in a separated distribution is a > >>> good idea > >>> (unless the pure-perl distribution requires the XS one, which renders > >>> the > >>> whole separation moot.) I'd rather move the pure-perl code into a > >>> ::PP > >>> module.
> >> The ::XS dist is required in practice. Observe: > >> > >> https://metacpan.org/source/HAARG/Devel-GlobalDestruction- > >> 0.13/Makefile.PL#L39 > >> https://metacpan.org/source/RIBASUSHI/Class-Accessor-Grouped- > >> 0.10010/Makefile.PL#L24 > >> https://metacpan.org/source/ETHER/B-Hooks-EndOfScope- > >> 0.13/Makefile.PL#L21 > >> > >> This is not a new problem, nor it is unusual. This is where the > >> toolchain is moving as a whole: XS is required when the underlying > >> environment allows it.
> > Sorry, but this approach is misguided. It's not the job of the tool > > chain to manage dependencies other than purely build-time > > dependencies. A clean separation is required for proper deployment > > audit and reproductibility. None of those hacks scale.
> I completely disagree with your qualification of "hacks", and disagree > with the "doesn't scale" claim - CPAN is a proof this approach does scale.
Clarification : I meant scale to configuration management systems, not to manual installs. I don't like to add ::XS modules to my puppet manifests every time XS is split out from a distribution, just to keep it working at an expected performance level. And manual upgrades don't work at scale, which was the original meaning of my remark. Show quoted text
> Thank you for considering this and clearly outlining your position. I > will start work on removing S::I from my dependency chains due to the > above vision incompatibilities.
I would personally recommend Sub::Util which is going to be a core module, since I expect that alternatives will be progressively out of fashion (due to Sub::Util coming with 5.22) Show quoted text
> A PR to fix the < 5.14 failures will be coming your way nevertheless, > within a day.
Thank you for that!
I just found this ticket after performing an update on my $work environment and hitting a build failure. Congratulations, you just broke Moose and everything in the cpan and darkpan that uses it! Please please please could you revert this change while appropriate alternatives are discussed?
On Wed Sep 10 08:08:28 2014, RGARCIA wrote: Show quoted text
> Clarification : I meant scale to configuration management systems, > not to manual installs. I don't like to add ::XS modules to > my puppet manifests every time XS is split out from a distribution, > just to keep it working at an expected performance level. And > manual upgrades don't work at scale, which was the original meaning > of my remark.
You shouldn't need to do that in the first place. The standard approach is for the baseline module to require the XS dist if a compiler is detected, so the change is transparent. If your configuration management system isn't following dependencies, then it's going to blow up any time a transitive dependency gets added somewhere, so the problem already exists. Every large scale perl deployment I've ever built would handle this change fine - and in fact, most of those deployments have handled the prior art riba describes fine. Basically, you're imagining problems that, in practice, have turned out not to exist :) Show quoted text
> I would personally recommend Sub::Util which is going to be a core > module, since I expect that alternatives will be progressively out > of fashion (due to Sub::Util coming with 5.22)
Yes, we're co-ordinating with LeoNerd on that already. Which makes it even more important that Sub::Identify stays as a working solution for older perls, from my POV. Show quoted text
> > A PR to fix the < 5.14 failures will be coming your way nevertheless, > > within a day.
> > Thank you for that!
This needs a fast turnaround, btw - you've trashed Moose, Catalyst and everything downstream of them with this release. I'm aware you're not an idiot so I'm not going to yell at you over it but I do reserve the right to say "dude, PLEASE never do that again" in a pained voice to you the next time we have a beer together :)
On 2014-09-10 02:57:42, RIBASUSHI wrote: Show quoted text
> On Wed Sep 10 11:28:05 2014, RGARCIA wrote:
> > > > Sorry then, the module just does not work on ancient perls, hence the > > version requirement.
Pre-5.14 is, regrettably, not yet ancient. The Perl-Toolchain-Gang is still committed to supporting down to perl 5.8 in normal cases, and even accepting non-disruptive patches for earlier versions if anyone is willing to write them. The Moose project has a stated policy of supporting 5.10+ and accepting patches for 5.8. Show quoted text
> This is not true. There are two things that make the version bump > unacceptable: > > 1) The XS portion requires newer macros yes, but nothing prevents you > from having a couple of IFDEF's. Moreover extra PPPort application is > likely to make the problem go away altogether
I would request that a newer ppport.h be applied to see if this is sufficient, as it sounds like the simplest solution of all. And, then, adding IFDEFs in code. Show quoted text
> 2) (much more importantly) The module always had a pure-perl > implmentation which works all the way back to what *I* consider > ancient. If you are not interested in doing the work required for (1), > which is entirely your right, you must modify your builder to skip > building XS on < 5.14. This way you get the C code in whatever shape > you prefer, and yet nobody gets broken deployments.
I would consider it acceptable for the distribution to fall back to a pure-perl implementation for pre-5.14 installations, if this is documented. What *isn't* acceptable is for the code to simply stop installing on pre-5.14 perls, as this breaks all upstream dependencies which have stated goals of continuing to work on these versions, which includes Moose. Leaving the dependency chain broken is *NOT* an option. Please, in future, make breaking changes in an alpha release first so you can safely gauge the impact before disrupting everyone downstream.
On 2014-09-10 04:47:42, RGARCIA wrote: Show quoted text
> I don't think that splitting XS code in a separated distribution is a > good idea > (unless the pure-perl distribution requires the XS one, which renders > the > whole separation moot.) I'd rather move the pure-perl code into a ::PP > module.
The PP dist can conditionally require the XS one if a compiler is available. This is very easy to do with just a few lines in Makefile.PL. I can even write the code for you. (The XS dist just needs to be stand-alone, and not depend on things in the PP dist, or a circular dependency will arise.)
I have now uploaded 0.06 to CPAN which removes the build requirement on 5.14.1. Please note that this is an emergency-fix release that *should* work mostly everywhere but that I plan to polish further in the coming days. So I'm keeping that ticket open for followup. Why wasn't I informed that my little toy module was used by half of CPAN (tm) ? :)
On Wed Sep 10 12:57:59 2014, ETHER wrote: Show quoted text
> The PP dist can conditionally require the XS one if a compiler is > available. This is very easy to do with just a few lines in > Makefile.PL. I can even write the code for you. (The XS dist just > needs to be stand-alone, and not depend on things in the PP dist, or a > circular dependency will arise.)
I was not speaking about build dependencies but installation dependencies.
I have now uploaded 0.07 to CPAN that fixes a failing test on versions <5.16 due to a coding mistake on my part.
On Wed Sep 10 17:12:39 2014, RGARCIA wrote: Show quoted text
> Why wasn't I informed that my little toy module was used by half of > CPAN (tm) ? :)
You were a freaking pumpking. Of course we assumed yours was the right one to use for this level of internals fuckery.
Closing due to more testing showing that the compatibility is restored. Moreover next upcoming release will have a prominent notice advertising Sub::Util instead.
Le 2014-09-16 16:21:42, RGARCIA a écrit :
Show quoted text
> Closing due to more testing showing that the compatibility is
> restored.
> Moreover next upcoming release will have a prominent notice
> advertising Sub::Util instead.

Thanks for the fixes!

-- 
Olivier Mengué - http://perlresume.org/DOLMEN - https://gratipay.com/dolmen/