Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
abraxxa opened this issue Mar 4, 2024 · 13 comments
Open

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

abraxxa opened this issue Mar 4, 2024 · 13 comments

Comments

@abraxxa
Copy link

abraxxa commented Mar 4, 2024

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
Copy link
Owner

skaji commented Mar 4, 2024

Can you provide build.log?

Especially, I want to know which resolver you use.

@abraxxa
Copy link
Author

abraxxa commented Mar 6, 2024

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
Copy link
Owner

skaji commented Mar 6, 2024

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
Copy link
Owner

skaji commented Mar 6, 2024

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
Copy link
Author

abraxxa commented Mar 6, 2024

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
Copy link
Owner

skaji commented Mar 8, 2024

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

@abraxxa
Copy link
Author

abraxxa commented Mar 11, 2024

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 abraxxa closed this as completed Mar 11, 2024
@abraxxa abraxxa reopened this Mar 11, 2024
@abraxxa
Copy link
Author

abraxxa commented Mar 11, 2024

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
Copy link
Author

abraxxa commented Mar 11, 2024

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
Copy link
Author

abraxxa commented Mar 11, 2024

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
Copy link
Owner

skaji commented Mar 19, 2024

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
Copy link
Author

abraxxa commented Mar 19, 2024

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

@skaji
Copy link
Owner

skaji commented Mar 19, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants