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

Unable to update pacakges with extras #439

Open
PeterJCLaw opened this issue Jan 4, 2024 · 3 comments
Open

Unable to update pacakges with extras #439

PeterJCLaw opened this issue Jan 4, 2024 · 3 comments
Labels

Comments

@PeterJCLaw
Copy link
Contributor

Given input:

ibis-framework

which produces an output file with many dependencies, including:

ibis-framework==7.2.0
pins[gcs]==0.8.4  # change this line manually to 0.8.3

Attempting to update pins from 0.8.3 to the latest (0.8.4 at the time of writing) doesn't seem to work.

Running this with a single layer of requirements results in no changes and no errors.
With several layers of requirements an error is emitted:

Package pins[gcs] was resolved to different versions in different environments: 0.8.4 and 0.8.3
...
RuntimeError: Please add constraints for the package version listed above

With single-layer input:

ibis-framework
pins==0.8.3

A similar error is present:

Could not find a version that matches fsspec<2023.9.0,==2023.12.2,>=0.8.0 (from pins[gcs]==0.8.3->-r requirements/base.in (line 2))
...
  fsspec==2023.12.2 (from gcsfs==2023.12.2.post1->pins[gcs]==0.8.3->-r requirements/base.in (line 2))
  fsspec<2023.9.0,>=0.8.0 (from pins[gcs]==0.8.3->-r requirements/base.in (line 2))
...
RuntimeError: Failed to pip-compile requirements/base.in
@peterdemin
Copy link
Owner

Could you please try experimenting with --autoresolve and --backtracking flags?

@PeterJCLaw
Copy link
Contributor Author

For the case of a single layer, pins not present in the .in file, but currently being at 0.8.3:

  • --autoresolve solves the issue (upgrade happens as desired)
  • --backtracking has no effect (no error, also no upgrade)

For the case of a single layer, with pins==0.8.3 being in the .in file:

  • --autoresolve has no effect (i.e: still errors)
  • --backtracking solves the issue (initial locking happens fine)

The cases with more layers don't seem quite the same; I'm currently working out exactly what they do.

I already had --autoresolve in my original but forgot to use that in my cut-down. Adding --backtracking to my original requirements hits other issues (possibly related to #413).

@peterdemin
Copy link
Owner

Thanks for reporting the issue. I think I saw something similar in the past. I don't have time to debug/fix it, but I'd be happy to review/merge a PR and publish a new release.

@peterdemin peterdemin added the bug label Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants