BBC Module::Install broken by 0301e899536a22752f40481d8a1d141b7a7dda82 #16300
Comments
From zefram@fysh.orgCreated by zefram@fysh.orgModule::Install fails one of its tests since core commit Perl Info |
From zefram@fysh.orgI wrote:
Turns out that Module::Install::DSL has some rather convoluted code in $ perl5.27.6 -lwe 'print "main program"; INIT { print "init block"; } BEGIN { print "begin block"; exit 0; }' That is, after a BEGIN block performs an exit(0), perl used to run This situation is not precisely the exit(0) from a CHECK block that was Module::Install::DSL does have a genuine, if not entirely respectable, However, as far as I can see there's no need at all for the module to -zefram |
From zefram@fysh.orgI have opened [rt.cpan.org #123867 (https://rt.cpan.org/Public/Bug/Display.html?id=123867) ] on the Module-Install side. -zefram |
From @LeontOn Tue, Dec 12, 2017 at 8:13 PM, Zefram <zefram@fysh.org> wrote:
Given Module::Install's rather unfortunate bundling nature, that would Leon |
|
The RT System itself - Status changed from 'new' to 'open' |
From @LeontOn Tue, Dec 12, 2017 at 11:03 PM, Leon Timmermans <fawaka@gmail.com> wrote:
Well, all 119 modules using Module::Install::DSL, Module::Install in Leon |
From @xsawyerxOn 12/13/2017 12:04 AM, Leon Timmermans wrote:
That is indeed a pain. What is the cost of reverting this commit instead? |
From @cpansproutOn Sun, 17 Dec 2017 03:06:01 -0800, xsawyerx@gmail.com wrote:
I seem to remember an old blog or list post by Michael Schwern predicting this very problem with Module::Install.
Buggy, unpredictable behaviour, unless you can memorise the list of complex rules for when exit does and does not prevent other blocks from running. -- Father Chrysostomos |
From @xsawyerxOn 12/17/2017 09:17 PM, Father Chrysostomos via RT wrote:
Are you referring to long-term or immediate effect? I'm wondering about temporary revert. |
From @cpansproutOn Mon, 18 Dec 2017 07:39:32 -0800, xsawyerx@gmail.com wrote:
I’m referring to the bugs that Zefram fixed, which went even deeper than Zefram realized when he was fixing them. So at present nobody but he can predict which blocks will trigger at what time if ‘exit’ is used in them.
That might be a good approach: revert and then reinstate after 5.28. In the mean time, a bunch of modules need to be released. -- Father Chrysostomos |
From @xsawyerxOn 12/18/2017 07:39 PM, Father Chrysostomos via RT wrote:
Exactly. A better phrasing for my question is "How problematic would it Zefram, can you please weigh in here? |
From zefram@fysh.orgSawyer X wrote:
The impact of retaining the bug for another year should be low. -zefram |
From @karenetheridgeOn Thu, 21 Dec 2017 23:03:05 -0800, zefram@fysh.org wrote:
Is kicking the can down the road a significant win? |
From @andkAlso affected (discovered by Slaven): MANWAR/Test-Strict-0.40.tar.gz -- |
From @xsawyerxOn 12/22/2017 09:02 AM, Zefram wrote:
I'm not sure there is such readiness. We are fairly behind. Considering this fix is for such a long-standing low-priority bug, |
From zefram@fysh.orgSawyer X wrote:
You mean... a deprecation warning? Technically, if we revert perl_parse() to return zero for exit(0), -zefram |
From @xsawyerxOn 12/25/2017 10:29 AM, Zefram wrote:
Yes.
Wherever we can warn here instead of die, it is better. Where we cannot, |
From zefram@fysh.orgFollowing discussion with Sawyer, where he determined that I tried adding a deprecation warning, but this turned out to cause noise. We expect to fix the bug again during the 5.29 cycle. This would consist -zefram |
From @iabynOn Wed, Dec 27, 2017 at 09:23:52PM +0000, Zefram wrote:
Since this change has been reverted for 5.28, I presume I can remove this -- |
From @xsawyerxOn 04/20/2018 12:36 AM, Dave Mitchell wrote:
Yup. |
From @khwilliamsonOn Fri, 20 Apr 2018 03:54:26 -0700, xsawyerx@gmail.com wrote:
Pinging this ticket -- |
From @karenetheridgeOn Thu, 28 Mar 2019 19:33:04 -0700, khw wrote:
I've been re-releasing all the modules I am aware of (that I have the ability to) that use Module::Install::DSL; I think the upper portions of the cpan river are now clean. Are we able to assess the remaining impact to the river, and perhaps establish the final list of distributions that are still of concern? |
From @jkeenanOn Sat, 30 Mar 2019 03:54:10 GMT, ether wrote:
For what it's worth ... I went to this (possibly inaccurate) list of CPAN distributions which are dependent upon Module::Install: http://deps.cpantesters.org/depended-on-by.pl?dist=Module-Install I extracted the 127 top-level distros, then excluded all distros beginning with Acme, Bundle or Task. That left 114 distros, which I attempted to install against Perl 5 blead (commit 930ded6, Apr 2 2019) on FreeBSD-11.2 (threaded) using cpanm as the installer. (I.e., the same approach I take toward monthly testing of the "CPAN-River-3000".) Certain modules failed to install for reasons that were expected given that they, or their prerequisites, do not get a PASS grade during the monthly CPAN-River-3000 process. Other modules failed to install because of upstream breakage in blead. However, I couldn't identify any distributions which failed due to Module::Install itself. Thank you very much. |
From @xsawyerxOn 4/3/19 2:53 PM, James E Keenan via RT wrote:
Can you share this list, please? |
From @jkeenanOn 4/7/19 1:43 AM, Sawyer X wrote:
Attached. |
From @jkeenanModule::Install |
From @jkeenanOn Wed, 03 Apr 2019 11:53:39 GMT, jkeenan wrote:
CPANtesters currently all green for this distro. http://matrix.cpantesters.org/?dist=Module-Install;perl=5.29.10;reports=1 Can this ticket be marked Resolved? Thank you very much. -- |
From @iabynOn Sat, Apr 13, 2019 at 07:02:10PM -0700, James E Keenan via RT wrote:
Not really. The change in blead, v5.27.6-180-g0301e89953, that broke M::I I'm going to move this from 5.30.0 blocker to 5.32.0 blocker -- |
From @karenetheridgeOn Tue, 23 Apr 2019 08:03:46 -0700, davem wrote:
Since nothing on cpan seems to be affected anymore, this should be safe to resolve |
From @jkeenanOn Fri, 26 Apr 2019 04:05:42 GMT, ether wrote:
I have created the following branch: smoke-me/jkeenan/rt-132577-module-install ... in which the reverted portion of the original commit is re-applied. This can facilitate CPAN smoking (which we will have to arrange). Thank you very much. -- |
|
What needs to be done here, if anything, to at least remove this from being a 5.32 blocker? |
|
I don't think it needs to be a blocker. Applying the full "fix" here would still break a number of modules, for very little benefit. It isn't hard to fix the modules, but it won't happen on a short time frame. |
|
It sounds like there is nothing actionable here, so we're ok to close the case? |
toddr
added
the
Closable?
|
Considering the length of this ticket, I'd suggest we open a ticket for the issue that's left and neither this new ticket nor this ticket should be blockers. (But to be honest, at this point, I've lost what issue remains...) |
jkeenan
added
BBC
|
With no action other than "we can close this, right?" in two years, I'm closing this. |
jkeenan
removed
the
Closable?
|
This ticket is related to #20161 and is still causing breakage 5 years later. Has there been enough time for Module::Install to upgrade yet? |
|
Here is the list of dists that would be impacted by this: |
|
So none of them have upgraded in the 5 years since this came up last time? |
|
IM reopening this ticket. I think we should bit the bullet already on this. Its been too long. |
|
I think i can work around this issue by simply treating INIT blocks from Module::Install::DSL as BEGIN blocks. |
This converts INIT {} blocks from the Module::Install::DSL
namespace into BEGIN blocks. This works around the bug reported in
GH Issue #16300. (Hopefully, not fully tested yet.)
This converts INIT {} blocks from the Module::Install::DSL
namespace into BEGIN blocks. This works around the bug reported in
GH Issue #16300. (Hopefully, not fully tested yet.)
|
In my rudimentary testing I was able run the Makefile.pl, assuming i overload @inc to include ".". I didnt actually install this commit and try it end to end, but in my testing i was able to prove to myself that I could convert INIT blocks into BEGIN blocks on a per namespace basis, which means we can have our cake and eat it too. And Module::Install earns the infamy of having code in perl to work around its bugs. :-) Whether we want the warning (imo yes) is an open question. Converting INIT blocks to BEGIN blocks is a specific namespace is sufficiently icky i feel it deserves a warning, but the people who see the warning by and large wont be the people who own the code. So it might just be better to get all those modules released. |
This converts INIT {} blocks from the Module::Install::DSL
namespace into BEGIN blocks. This works around the bug reported in
GH Issue #16300. (Hopefully, not fully tested yet.)
This converts INIT {} blocks from the Module::Install::DSL
namespace into BEGIN blocks. This works around the bug reported in
GH Issue #16300. (Hopefully, not fully tested yet.) Which in turn
should allow us to close the bug in #2754.
See also PR: #20168 and Issue: #20161 both of which are blocked by
this.
This converts INIT {} blocks from the Module::Install::DSL
namespace into BEGIN blocks. This works around the bug reported in
GH Issue #16300. (Hopefully, not fully tested yet.) Which in turn
should allow us to close the bug in #2754.
See also PR: #20168 and Issue: #20161 both of which are blocked by
this.
This converts INIT {} blocks from the Module::Install::DSL
namespace into BEGIN blocks. This works around the bug reported in
GH Issue Perl#16300. (Hopefully, not fully tested yet.) Which in turn
should allow us to close the bug in Perl#2754.
See also PR: Perl#20168 and Issue: Perl#20161 both of which are blocked by
this.
Migrated from rt.perl.org#132577 (status was 'open')
Searchable as RT132577$
The text was updated successfully, but these errors were encountered: