Doesn't fail if dependency version can't be satisfied

[abraxxa]

I often release a new version to CPAN and require it in our DarkPAN code immediatly. When not waiting long enough, even if the newest version is specified in cpanfile, cpm installs the previous one (current CPAN index) and doesn't fail with an error that it can't satisfy the requirements. This leads to errors most at the time in the tests which are annoying and often hard to understand.

[skaji]

Can you provide build.log?

Especially, I want to know which resolver you use.

[abraxxa]

This is part of our Gitlab CI pipeline, relevant lines:

ENV CPANINSTALLER cpm install -g --show-build-log-on-failure --resolver 02packages,$CPAN_MIRROR --resolver metadb
dzil authordeps --missing | xargs $CPANINSTALLER     && dzil listdeps --author --missing | xargs $CPANINSTALLER
...
DONE install Net-Silverpeak-Orchestrator-0.009000
...

CPAN_MIRROR is set as Gitlab CI variable to our darkpan URL.

The cpanfile contained version 0.010000, but 0.009000 was installed without cpm aborting with a non-zero return code to end the CI pipeline step with an error.

[skaji]

02packages resolver checks version constraints.

Again, can you provide build.log? From build.log, we see which resolver is used for resolving modules in question. And also you should check if the module versions are correctly specified in 02packages.details.txt.gz in your darkpan.

[skaji]

On a different note, I wouldn't recommend using cpm with xargs. Just use cpm with - (reading from STDIN):

dzil authordeps --missing | cpm install -

[abraxxa]

No, I can't provide the build.log from the run as Gitlab CI deletes the container after it finishes, I only have the log output where I extracted the relevant lines from.

Our DarkPAN only has our dists, not a CPAN mirror. It uses Mojo::Darkpan if that matters.

[skaji]

If you cannot provide build.log, then I don't think we can continue the investigation any further.

[abraxxa]

I've tried to generate the build.log locally by requiring a newer version as exists on CPAN. In the process I found out the cause myself: dzil listdeps --author --missing returns a list of dist names without version number. In my test case with a cpanfile containing version 0.011000 of Net::Silverpeak::Orchestrator:

$ dzil listdeps --author --missing
Net::Silverpeak::Orchestrator

If I pipe that into cpm via xargs it of course can't know that I want a newer version 🤦🏻‍♂️

Using your suggestion to not use xargs wouldn't change anything as dzil still wouldn't output a version requirement.

Do you have a suggestion how to call cpm to not lose the version requirements? Forget that, I just found it myself: dzil listdeps has a --version parameter that isn't on by default. With that cpm fails! 😄

[abraxxa]

Too soon! With --versions it always fails because it tries to find dists named = and all version numbers.

@skaji do you have a suggestion how to pass the dzil generated requirements with version numbers to cpm? Using the cpanfile isn't enough as dzil plugins add requirements, for example for generated tests.

[abraxxa]

I found dzil's --cpan-versions parameter which looked like it would solve the issue, but it still fails:

FAIL resolve Array::Utils~"0.5"
FAIL resolve Class::Autouse~"2.01"
FAIL resolve Config::General~"2.65"
...

[abraxxa]

Another finding, it works with xargs, fails with -:

$ echo 'Type::Tiny~"2.004"' | cpm install -
DONE install install is up to date. (0.01)
FAIL resolve -
0 distribution installed.

$ echo 'Type::Tiny~"2.004"' | xargs cpm install
DONE install Exporter-Tiny-1.006002 (using prebuilt)
DONE install Type-Tiny-2.004000 (using prebuilt)
2 distributions installed.

[skaji]

The correct syntax is Type::Tiny~2.004.

It seems xargs removes quotes. https://unix.stackexchange.com/questions/38148/why-does-xargs-strip-quotes-from-input

[abraxxa]

So dzil --cpan-versions returns the versions with double quotes and cpm expects them without?

[skaji]

Yes. And cpanminus also expects Type::Tiny~2.004.