Skip Menu |
 

This queue is for tickets about the List-MoreUtils CPAN distribution.

Report information
The Basics
Id: 122875
Status: open
Priority: 0/
Queue: List-MoreUtils

People
Owner: Nobody in particular
Requestors: ANDK [...] cpan.org
Cc: DBOOK [...] cpan.org
PLICEASE [...] cpan.org
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.423
Fixed in: (no value)

Attachments


Subject: Fails when List::MoreUtils::XS not installed
Download (untitled) / with headers
text/plain 1.1k
Diagnostics: Can't locate List/MoreUtils/XS.pm in @INC (you may need to install the List::MoreUtils::XS module) (@INC contains: /tmp/loop_over_bdir-8924-FYP1tx/List-MoreUtils-0.423-0/blib/lib /tmp/loop_over_bdir-8924-FYP1tx/List-MoreUtils-0.423-0/blib/arch /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.27.3/29fb/lib/site_perl/5.27.3/x86_64-linux-thread-multi /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.27.3/29fb/lib/site_perl/5.27.3 /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.27.3/29fb/lib/5.27.3/x86_64-linux-thread-multi /home/sand/src/perl/repoperls/installed-perls/host/k93msid/v5.27.3/29fb/lib/5.27.3 .) at /tmp/loop_over_bdir-8924-FYP1tx/List-MoreUtils-0.423-0/blib/lib/List/MoreUtils.pm line 14. BEGIN failed--compilation aborted at /tmp/loop_over_bdir-8924-FYP1tx/List-MoreUtils-0.423-0/blib/lib/List/MoreUtils.pm line 20. Compilation failed in require at t/xs/after.t line 7. BEGIN failed--compilation aborted at t/xs/after.t line 7. t/xs/after.t ...................... Dubious, test returned 2 (wstat 512, 0x200) No subtests run Full sample fail report: http://www.cpantesters.org/cpan/report/d16e2854-8714-11e7-906a-d8267b9c3273 HTH&&Thanks,
Download (untitled) / with headers
text/plain 578b
This is unfortunately a false negative :( When you don't specify anything (I don't see how Makefile.PL in invoked neither what happened to the recommended dependencies), List::MoreUtils::XS is put into recommendations and the xs-tests are activated. When you specify PUREPERL_ONLY=1, none of that happens. Since it was a clear, explicit wish that List::MoreUtils::XS should be installed when possible (see https://github.com/perl5-utils/List-MoreUtils/issues/25). I appreciate any (reasonable) suggestion to keep even unwanted users as happy as possible. Best regards, Jens
Download (untitled) / with headers
text/plain 2.4k
On Wed Aug 23 05:37:50 2017, REHSACK wrote: Show quoted text
> This is unfortunately a false negative :( > > When you don't specify anything (I don't see how Makefile.PL in > invoked neither what happened to the recommended dependencies), > List::MoreUtils::XS is put into recommendations and the xs-tests are > activated. > > When you specify PUREPERL_ONLY=1, none of that happens. > > Since it was a clear, explicit wish that List::MoreUtils::XS should be > installed when possible (see https://github.com/perl5-utils/List- > MoreUtils/issues/25). > > I appreciate any (reasonable) suggestion to keep even unwanted users > as happy as possible. > > Best regards, > Jens
There are a few issues with the current setup. First, the xs vs pp options aren't working as intended. They are intended to toggle List::MoreUtils::XS as a recommendation and running the xs tests. They are actually only controlling the tests. META_MERGE is entirely ignored on user machines. Instead, LMU::XS is always listed as a recommendation, because that is how the META_MERGE option is set on the author machine. On user machines, that metadata is copied from the META.json file, only making adjustments based on the PREREQ_PM/BUILD_REQUIRES/TEST_REQUIRES options. This is a limitation in EUMM which I don't have a good workaround for at this time. Second is that List::MoreUtils::XS is only listed as a recommendation, yet is a hard requirement of the tests. This is the primary issue preventing users from installing this dist. The default behavior of the Makefile.PL is to enable the xs tests. But since LMU::XS is only ever listed as an optional prerequisite, most users will not have it installed or upgraded. To resolve this, the xs tests should skip themselves if an appropriate version of List::MoreUtils::XS is not available. The conventional way these XS-optional prerequisites have been handled elsewhere is by detecting if a compiler is available (using a tool like ExtUtils::HasCompiler) and based on that setting a hard prerequisite (PREREQ_PM) on the XS backend. If this approach was used, the xs tests could be enabled in the same way without having to check for LMU::XS themselves. The current conflict checking code also looks like it has some issues. It appears to only be removing the old arch versions of modules if they are in the perl core directories. This means upgrading from a pre-XS-split version in a local::lib won't work. The @killsite content also looks wrong, and will contain an extra trailing .pm.
Download (untitled) / with headers
text/plain 3.6k
On Wed Aug 23 10:37:45 2017, haarg wrote: Show quoted text
> On Wed Aug 23 05:37:50 2017, REHSACK wrote:
> > This is unfortunately a false negative :( > > > > When you don't specify anything (I don't see how Makefile.PL in > > invoked neither what happened to the recommended dependencies), > > List::MoreUtils::XS is put into recommendations and the xs-tests are > > activated. > > > > When you specify PUREPERL_ONLY=1, none of that happens. > > > > Since it was a clear, explicit wish that List::MoreUtils::XS should > > be > > installed when possible (see https://github.com/perl5-utils/List- > > MoreUtils/issues/25). > > > > I appreciate any (reasonable) suggestion to keep even unwanted users > > as happy as possible. > > > > Best regards, > > Jens
> > There are a few issues with the current setup. > > First, the xs vs pp options aren't working as intended. They are > intended to toggle List::MoreUtils::XS as a recommendation and running > the xs tests. They are actually only controlling the tests. > META_MERGE is entirely ignored on user machines. Instead, LMU::XS is > always listed as a recommendation, because that is how the META_MERGE > option is set on the author machine. On user machines, that metadata > is copied from the META.json file, only making adjustments based on > the PREREQ_PM/BUILD_REQUIRES/TEST_REQUIRES options. This is a > limitation in EUMM which I don't have a good workaround for at this > time.
Understood (more or less). So putting XS into PREREQ_PM and remove it from there when PUREPERL_ONLY is set to a true value would be recognized by EUMM and handled correctly? Show quoted text
> Second is that List::MoreUtils::XS is only listed as a recommendation, > yet is a hard requirement of the tests. This is the primary issue > preventing users from installing this dist. The default behavior of > the Makefile.PL is to enable the xs tests. But since LMU::XS is only > ever listed as an optional prerequisite, most users will not have it > installed or upgraded. To resolve this, the xs tests should skip > themselves if an appropriate version of List::MoreUtils::XS is not > available.
This cannot be reasonably tested - since you'll never know at this time whether XS has been installed but is broken or XS is not wanted. I explained that long and wide - but ... yeah ... people :) Show quoted text
> The conventional way these XS-optional prerequisites have been handled > elsewhere is by detecting if a compiler is available (using a tool > like ExtUtils::HasCompiler) and based on that setting a hard > prerequisite (PREREQ_PM) on the XS backend. If this approach was > used, the xs tests could be enabled in the same way without having to > check for LMU::XS themselves.
ExtUtils::HasCompiler is broken by design and was built and released to get rid of Config::AutoConf which noone had understood by noone wanted to learn. A lot of "flamewar" was because of this and I really hope this doesn't happen this time and here again - but the strong wish of removing XS availability approval out of List::MoreUtils led to this issue. It's a "wash me but don't make me wet" situation. Show quoted text
> The current conflict checking code also looks like it has some issues. > It appears to only be removing the old arch versions of modules if > they are in the perl core directories. This means upgrading from a > pre-XS-split version in a local::lib won't work. The @killsite > content also looks wrong, and will contain an extra trailing .pm.
Yeah - that might be true. I don't like this at all but took it from https://github.com/perl5-utils/List-MoreUtils/issues/22 as you recommended. I don't think perlbrews or local::libs shall be treated like an updatable user-package-tree. It is not, not all all.
Download (untitled) / with headers
text/plain 4.8k
On Wed Aug 23 10:55:04 2017, REHSACK wrote: Show quoted text
> On Wed Aug 23 10:37:45 2017, haarg wrote:
> > On Wed Aug 23 05:37:50 2017, REHSACK wrote:
> > > This is unfortunately a false negative :( > > > > > > When you don't specify anything (I don't see how Makefile.PL in > > > invoked neither what happened to the recommended dependencies), > > > List::MoreUtils::XS is put into recommendations and the xs-tests are > > > activated. > > > > > > When you specify PUREPERL_ONLY=1, none of that happens. > > > > > > Since it was a clear, explicit wish that List::MoreUtils::XS should > > > be > > > installed when possible (see https://github.com/perl5-utils/List- > > > MoreUtils/issues/25). > > > > > > I appreciate any (reasonable) suggestion to keep even unwanted users > > > as happy as possible. > > > > > > Best regards, > > > Jens
> > > > There are a few issues with the current setup. > > > > First, the xs vs pp options aren't working as intended. They are > > intended to toggle List::MoreUtils::XS as a recommendation and running > > the xs tests. They are actually only controlling the tests. > > META_MERGE is entirely ignored on user machines. Instead, LMU::XS is > > always listed as a recommendation, because that is how the META_MERGE > > option is set on the author machine. On user machines, that metadata > > is copied from the META.json file, only making adjustments based on > > the PREREQ_PM/BUILD_REQUIRES/TEST_REQUIRES options. This is a > > limitation in EUMM which I don't have a good workaround for at this > > time.
> > Understood (more or less). So putting XS into PREREQ_PM and remove it > from there when PUREPERL_ONLY is set to a true value would be recognized > by EUMM and handled correctly?
Yes, that would work correctly. Although it would end up with LMU::XS usually being a hard prerequisite. Show quoted text
>
> > Second is that List::MoreUtils::XS is only listed as a recommendation, > > yet is a hard requirement of the tests. This is the primary issue > > preventing users from installing this dist. The default behavior of > > the Makefile.PL is to enable the xs tests. But since LMU::XS is only > > ever listed as an optional prerequisite, most users will not have it > > installed or upgraded. To resolve this, the xs tests should skip > > themselves if an appropriate version of List::MoreUtils::XS is not > > available.
> > This cannot be reasonably tested - since you'll never know at this time > whether XS has been installed but is broken or XS is not wanted. > > I explained that long and wide - but ... yeah ... people :)
If the XS module is optional in the prerequisites, then it has to be optional in the tests. If you want to keep it as required in the tests, then it needs to be a hard prerequisite in the Makefile.PL. Show quoted text
>
> > The conventional way these XS-optional prerequisites have been handled > > elsewhere is by detecting if a compiler is available (using a tool > > like ExtUtils::HasCompiler) and based on that setting a hard > > prerequisite (PREREQ_PM) on the XS backend. If this approach was > > used, the xs tests could be enabled in the same way without having to > > check for LMU::XS themselves.
> > ExtUtils::HasCompiler is broken by design and was built and released > to get rid of Config::AutoConf which noone had understood by noone wanted > to learn. A lot of "flamewar" was because of this and I really hope this > doesn't happen this time and here again - but the strong wish of removing > XS availability approval out of List::MoreUtils led to this issue. > > It's a "wash me but don't make me wet" situation.
I'm not specifically advocating for ExtUtils::HasCompiler, although I do believe it is a good solution. The convention for this is to decide up front if we are going to use the XS version based on if a compiler is available, and allowing a user override (PUREPERL_ONLY). Then it becomes simple to control the XS prerequisite and any tests. I'm not certain which part of this you have a conflict with. If it's only the choice of EUHC, then using something else to detect the compiler would also make sense. Show quoted text
>
> > The current conflict checking code also looks like it has some issues. > > It appears to only be removing the old arch versions of modules if > > they are in the perl core directories. This means upgrading from a > > pre-XS-split version in a local::lib won't work. The @killsite > > content also looks wrong, and will contain an extra trailing .pm.
> > Yeah - that might be true. I don't like this at all but took it from > https://github.com/perl5-utils/List-MoreUtils/issues/22 as you recommended. > > I don't think perlbrews or local::libs shall be treated like an updatable > user-package-tree. It is not, not all all.
This seems an odd decision given that it isn't hard to support, and deploying and updating local::libs is very common. The code you are using is doing extra work to check for the core directories, when not doing those checks would allow it to work with local::lib seamlessly.
On Wed Aug 23 11:20:41 2017, haarg wrote: Show quoted text
> On Wed Aug 23 10:55:04 2017, REHSACK wrote:
> > On Wed Aug 23 10:37:45 2017, haarg wrote:
> > > On Wed Aug 23 05:37:50 2017, REHSACK wrote:
> > > > This is unfortunately a false negative :( > > > > > > > > When you don't specify anything (I don't see how Makefile.PL in > > > > invoked neither what happened to the recommended dependencies), > > > > List::MoreUtils::XS is put into recommendations and the xs-tests > > > > are > > > > activated. > > > > > > > > When you specify PUREPERL_ONLY=1, none of that happens. > > > > > > > > Since it was a clear, explicit wish that List::MoreUtils::XS > > > > should > > > > be > > > > installed when possible (see https://github.com/perl5-utils/List- > > > > MoreUtils/issues/25). > > > > > > > > I appreciate any (reasonable) suggestion to keep even unwanted > > > > users > > > > as happy as possible. > > > > > > > > Best regards, > > > > Jens
> > > > > > There are a few issues with the current setup. > > > > > > First, the xs vs pp options aren't working as intended. They are > > > intended to toggle List::MoreUtils::XS as a recommendation and > > > running > > > the xs tests. They are actually only controlling the tests. > > > META_MERGE is entirely ignored on user machines. Instead, LMU::XS > > > is > > > always listed as a recommendation, because that is how the > > > META_MERGE > > > option is set on the author machine. On user machines, that > > > metadata > > > is copied from the META.json file, only making adjustments based on > > > the PREREQ_PM/BUILD_REQUIRES/TEST_REQUIRES options. This is a > > > limitation in EUMM which I don't have a good workaround for at this > > > time.
> > > > Understood (more or less). So putting XS into PREREQ_PM and remove it > > from there when PUREPERL_ONLY is set to a true value would be > > recognized > > by EUMM and handled correctly?
> > Yes, that would work correctly. Although it would end up with LMU::XS > usually being a hard prerequisite.
How does dynamic_configuration=1 works then? What can be changed on user machines? The tests shall be coupled with the prereq. Show quoted text
> > > Second is that List::MoreUtils::XS is only listed as a > > > recommendation, > > > yet is a hard requirement of the tests. This is the primary issue > > > preventing users from installing this dist. The default behavior > > > of > > > the Makefile.PL is to enable the xs tests. But since LMU::XS is > > > only > > > ever listed as an optional prerequisite, most users will not have > > > it > > > installed or upgraded. To resolve this, the xs tests should skip > > > themselves if an appropriate version of List::MoreUtils::XS is not > > > available.
> > > > This cannot be reasonably tested - since you'll never know at this > > time > > whether XS has been installed but is broken or XS is not wanted. > > > > I explained that long and wide - but ... yeah ... people :)
> > If the XS module is optional in the prerequisites, then it has to be > optional in the tests. If you want to keep it as required in the > tests, then it needs to be a hard prerequisite in the Makefile.PL.
I want both be turned on and off with the same trigger. And it seems when default is both on and turned of dynamically is the preferred way (I'm unoppiniated here). Show quoted text
> > > The conventional way these XS-optional prerequisites have been > > > handled > > > elsewhere is by detecting if a compiler is available (using a tool > > > like ExtUtils::HasCompiler) and based on that setting a hard > > > prerequisite (PREREQ_PM) on the XS backend. If this approach was > > > used, the xs tests could be enabled in the same way without having > > > to > > > check for LMU::XS themselves.
> > > > ExtUtils::HasCompiler is broken by design and was built and released > > to get rid of Config::AutoConf which noone had understood by noone > > wanted > > to learn. A lot of "flamewar" was because of this and I really hope > > this > > doesn't happen this time and here again - but the strong wish of > > removing > > XS availability approval out of List::MoreUtils led to this issue. > > > > It's a "wash me but don't make me wet" situation.
> > I'm not specifically advocating for ExtUtils::HasCompiler, although I > do believe it is a good solution.
It lacks to much... Show quoted text
> The convention for this is to decide up front if we are going to use > the XS version based on if a compiler is available, and allowing a > user override (PUREPERL_ONLY). Then it becomes simple to control the > XS prerequisite and any tests. > > I'm not certain which part of this you have a conflict with. If it's > only the choice of EUHC, then using something else to detect the > compiler would also make sense.
... <haarg> i don't like Config::AutoConf, but i do think using it like i described for EUHC would be better than how things are now So the recommendation is, proving for XS build availability. And if at any point in time something better than Config::AutoConf comes around, it'll favoured. Show quoted text
> > > The current conflict checking code also looks like it has some > > > issues. > > > It appears to only be removing the old arch versions of modules if > > > they are in the perl core directories. This means upgrading from a > > > pre-XS-split version in a local::lib won't work. The @killsite > > > content also looks wrong, and will contain an extra trailing .pm.
> > > > Yeah - that might be true. I don't like this at all but took it from > > https://github.com/perl5-utils/List-MoreUtils/issues/22 as you > > recommended. > > > > I don't think perlbrews or local::libs shall be treated like an > > updatable > > user-package-tree. It is not, not all all.
> > This seems an odd decision given that it isn't hard to support, and > deploying and updating local::libs is very common. The code you are > using is doing extra work to check for the core directories, when not > doing those checks would allow it to work with local::lib seamlessly.
For me it's completely weird. If you have a small patch, I happily add that. I took the recommendation against my opinion - so I might have thoughts and opinions and decide _always_ for users.
Download (untitled) / with headers
text/plain 6.7k
On Wed Aug 23 11:45:29 2017, REHSACK wrote: Show quoted text
> On Wed Aug 23 11:20:41 2017, haarg wrote:
> > On Wed Aug 23 10:55:04 2017, REHSACK wrote:
> > > On Wed Aug 23 10:37:45 2017, haarg wrote:
> > > > On Wed Aug 23 05:37:50 2017, REHSACK wrote:
> > > > > This is unfortunately a false negative :( > > > > > > > > > > When you don't specify anything (I don't see how Makefile.PL in > > > > > invoked neither what happened to the recommended dependencies), > > > > > List::MoreUtils::XS is put into recommendations and the xs- > > > > > tests > > > > > are > > > > > activated. > > > > > > > > > > When you specify PUREPERL_ONLY=1, none of that happens. > > > > > > > > > > Since it was a clear, explicit wish that List::MoreUtils::XS > > > > > should > > > > > be > > > > > installed when possible (see https://github.com/perl5- > > > > > utils/List- > > > > > MoreUtils/issues/25). > > > > > > > > > > I appreciate any (reasonable) suggestion to keep even unwanted > > > > > users > > > > > as happy as possible. > > > > > > > > > > Best regards, > > > > > Jens
> > > > > > > > There are a few issues with the current setup. > > > > > > > > First, the xs vs pp options aren't working as intended. They are > > > > intended to toggle List::MoreUtils::XS as a recommendation and > > > > running > > > > the xs tests. They are actually only controlling the tests. > > > > META_MERGE is entirely ignored on user machines. Instead, > > > > LMU::XS > > > > is > > > > always listed as a recommendation, because that is how the > > > > META_MERGE > > > > option is set on the author machine. On user machines, that > > > > metadata > > > > is copied from the META.json file, only making adjustments based > > > > on > > > > the PREREQ_PM/BUILD_REQUIRES/TEST_REQUIRES options. This is a > > > > limitation in EUMM which I don't have a good workaround for at > > > > this > > > > time.
> > > > > > Understood (more or less). So putting XS into PREREQ_PM and remove > > > it > > > from there when PUREPERL_ONLY is set to a true value would be > > > recognized > > > by EUMM and handled correctly?
> > > > Yes, that would work correctly. Although it would end up with > > LMU::XS > > usually being a hard prerequisite.
> > How does dynamic_configuration=1 works then? What can be changed on > user machines? > The tests shall be coupled with the prereq.
Prerequisites can be changed under dynamic_config. What I meant by this making it a hard prerequisite is that it would by default be a hard prereq unless you also add the compiler detection. Show quoted text
>
> > > > Second is that List::MoreUtils::XS is only listed as a > > > > recommendation, > > > > yet is a hard requirement of the tests. This is the primary > > > > issue > > > > preventing users from installing this dist. The default behavior > > > > of > > > > the Makefile.PL is to enable the xs tests. But since LMU::XS is > > > > only > > > > ever listed as an optional prerequisite, most users will not have > > > > it > > > > installed or upgraded. To resolve this, the xs tests should skip > > > > themselves if an appropriate version of List::MoreUtils::XS is > > > > not > > > > available.
> > > > > > This cannot be reasonably tested - since you'll never know at this > > > time > > > whether XS has been installed but is broken or XS is not wanted. > > > > > > I explained that long and wide - but ... yeah ... people :)
> > > > If the XS module is optional in the prerequisites, then it has to be > > optional in the tests. If you want to keep it as required in the > > tests, then it needs to be a hard prerequisite in the Makefile.PL.
> > I want both be turned on and off with the same trigger. And it seems > when default is both on and turned of dynamically is the preferred > way (I'm unoppiniated here). >
> > > > The conventional way these XS-optional prerequisites have been > > > > handled > > > > elsewhere is by detecting if a compiler is available (using a > > > > tool > > > > like ExtUtils::HasCompiler) and based on that setting a hard > > > > prerequisite (PREREQ_PM) on the XS backend. If this approach was > > > > used, the xs tests could be enabled in the same way without > > > > having > > > > to > > > > check for LMU::XS themselves.
> > > > > > ExtUtils::HasCompiler is broken by design and was built and > > > released > > > to get rid of Config::AutoConf which noone had understood by noone > > > wanted > > > to learn. A lot of "flamewar" was because of this and I really hope > > > this > > > doesn't happen this time and here again - but the strong wish of > > > removing > > > XS availability approval out of List::MoreUtils led to this issue. > > > > > > It's a "wash me but don't make me wet" situation.
> > > > I'm not specifically advocating for ExtUtils::HasCompiler, although I > > do believe it is a good solution.
> > It lacks to much... >
> > The convention for this is to decide up front if we are going to use > > the XS version based on if a compiler is available, and allowing a > > user override (PUREPERL_ONLY). Then it becomes simple to control the > > XS prerequisite and any tests. > > > > I'm not certain which part of this you have a conflict with. If it's > > only the choice of EUHC, then using something else to detect the > > compiler would also make sense.
> > ... > <haarg> i don't like Config::AutoConf, but i do think using it like i > described for EUHC would be better than how things are now > > So the recommendation is, proving for XS build availability. And if > at any point in time something better than Config::AutoConf comes > around, it'll favoured. >
> > > > The current conflict checking code also looks like it has some > > > > issues. > > > > It appears to only be removing the old arch versions of modules > > > > if > > > > they are in the perl core directories. This means upgrading from > > > > a > > > > pre-XS-split version in a local::lib won't work. The @killsite > > > > content also looks wrong, and will contain an extra trailing .pm.
> > > > > > Yeah - that might be true. I don't like this at all but took it > > > from > > > https://github.com/perl5-utils/List-MoreUtils/issues/22 as you > > > recommended. > > > > > > I don't think perlbrews or local::libs shall be treated like an > > > updatable > > > user-package-tree. It is not, not all all.
> > > > This seems an odd decision given that it isn't hard to support, and > > deploying and updating local::libs is very common. The code you are > > using is doing extra work to check for the core directories, when not > > doing those checks would allow it to work with local::lib seamlessly.
> > For me it's completely weird. If you have a small patch, I happily > add that. I took the recommendation against my opinion - so I might > have thoughts and opinions and decide _always_ for users.
I'll look at providing a patch for this. It is a separate issue from the primary focus of this ticket anyway.
Download (untitled) / with headers
text/plain 448b
This breaks installation of this module and quite a lot of downstream modules (looking at https://metacpan.org/requires/module/List::MoreUtils?p=1&size=100&sort=%5B%5B2%2C1%5D%5D, about 900). Would it be possible to put a quick fix in place, to unbreak all these modules, and then sort out the issue in an ideal way without any time pressure? Reverting to the previous version would be better than not being able to install it at all, IMHO. /J
Download (untitled) / with headers
text/plain 161b
There was a trial version out for a quite reasonable time. No, a revert is not reasonable and yes, I deal this with priority. Rushing something is insane anyway.
Download (untitled) / with headers
text/plain 847b
On 20170904T173514Z, REHSACK wrote: Show quoted text
> There was a trial version out for a quite reasonable time.
Just for the sake of revelation: There was a trial release out for *one* week. And this week should have been enough to *prevent* this release. Test results available from http://matrix.cpantesters.org/?dist=List-MoreUtils+0.420_001. It has a pass to fail ratio of 1:9. Show quoted text
> No, a > revert is not reasonable and yes, I deal this with priority. Rushing > something is insane anyway.
Please reconsider your position. I'd recommend a revert too. For those watching this from home: if you're using CPAN.pm, you can workaround this fuckup with the following distroprefs file: https://github.com/andk/cpanpm/commit/a8be5247e6d2784617faf9a59c8e6720ed81eff8 It simply prevents that your cpan shell ever tries to install this broken release. Good luck,
Download (untitled) / with headers
text/plain 1.9k
On Mon Sep 04 14:25:39 2017, ANDK wrote: Show quoted text
> On 20170904T173514Z, REHSACK wrote:
> > There was a trial version out for a quite reasonable time.
> > Just for the sake of revelation: > > There was a trial release out for *one* week. And this week should > have been enough to *prevent* this release. Test results available > from http://matrix.cpantesters.org/?dist=List-MoreUtils+0.420_001. It > has a pass to fail ratio of 1:9.
At which time? Was there on the web-site on 22 Aug 2017 08:29:26 GMT or yesterday? Unfortunately that's a big difference and at the time I prepared the release, there was at least a handful with issues. Together with my experience with CPAN.pm (which installs recommended and even fails if a recommendation failed to install), I rated that as fairly ok. When the picture changes, drop me a note (what happens yesterday) and do not expect I follow an unknown checklist. Show quoted text
> > No, a > > revert is not reasonable and yes, I deal this with priority. Rushing > > something is insane anyway.
> > > Please reconsider your position. I'd recommend a revert too.
For several reasons a revert hurts real users while a fix just hurts cpantesters. If you strongly need to install List::MoreUtils using a client not supporting recommends, I consider relying on the feature supported since 0.400: $ env PUREPERL_ONLY=1 perl Makefile.PL $ env PUREPERL_ONLY=1 cpan List::MoreUtils If you want to speed up a 0.424 fixing just the recommend/require-behavior, check https://github.com/perl5-utils/List-MoreUtils/commit/7a9b063af67eee688377d1060c1b73df3e394eef Show quoted text
> For those watching this from home: if you're using CPAN.pm, you can > workaround this fuckup with the following distroprefs file: > > https://github.com/andk/cpanpm/commit/a8be5247e6d2784617faf9a59c8e6720ed81eff8 > > It simply prevents that your cpan shell ever tries to install this > broken release.
This breaks situation for users relying on new functions of List::MoreUtils 0.423. Show quoted text
> Good luck,
Seriously? Cheers, Jens
Download (untitled) / with headers
text/plain 381b
For the meta->recommend vs. PREREQ_PM a 0.424_001 is released. This tests one more thing I'm interested in - the expected 0.425 will have the requirement for List::MoreUtils::XS in deployed META.yml and will remove that on $ PERL__MM_OPT="PUREPERL_ONLY=1" ... If one has a sane argument leaving xs-tests out for now and what is required to have them in, please speak up soon'ish.
0.425 out which might or might not make CPAN Testers much greener
Subject: LMU-0.424_001-Testers-Matrix.png
LMU-0.424_001-Testers-Matrix.png
Download (untitled) / with headers
text/plain 443b
On Wed Sep 06 05:20:38 2017, REHSACK wrote: Show quoted text
> 0.425 out which might or might not make CPAN Testers much greener
This solves the issue in https://github.com/perl5-utils/List-MoreUtils/issues/25 , and the xs tests seem to be correctly skipped when not requiring LMU::XS. The only remaining user-experience issue that I can see is that if PUREPERL_ONLY=1 is not specified but there is no compiler, the dependency of LMU::XS will fail to install.
Download (untitled) / with headers
text/plain 206b
There can be much more preventing successful installing LMU::XS than a missing compiler. I postpone that approval because of the burning situation. It's still priority, but no "immediate reaction" required.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.