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.
![Wed Sep 06 05:20:38 2017 (424.1k) by REHSACK [...] cpan.org](/Ticket/Attachment/1747426/939938/LMU-0.424_001-Testers-Matrix.png){kind=link}