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

Inconsistent lockfile with pypi-dependencies: conda dep appears twice in packages #1367

Closed
2 tasks done
fpaniagua opened this issue May 10, 2024 · 0 comments · Fixed by mamba-org/rattler#673
Closed
2 tasks done
Labels
bug Something isn't working

Comments

@fpaniagua
Copy link

Checks

  • I have checked that this issue has not already been reported.

  • I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

# pyproject.toml
[project]
name = "pixi-example"
requires-python = ">=3.8"

[tool.pixi.project]
name = "pixi-example"
channels = ["conda-forge"]
platforms = ["linux-64", "osx-arm64"]

[tool.pixi.tasks]

[tool.pixi.feature.test.dependencies]
python = "3.8.*"
py = "==1.11.0"

[tool.pixi.feature.test.pypi-dependencies]
python_dateutil =  "*"

[tool.pixi.environments]
default = {features = ["test"], solve-group = "default"}
test = {features = ["test"], solve-group = "default"}

Generate lock file

pixi install

Re-Generate lock file, and compare diff

mv pixi.lock pixi.old.lock && pixi install
diff pixi.old.lock pixi.lock

You may need to do re-gen more than once.

Issue description

I've noticed this specifically with py, which was an indirect dep. Moved up to minimize example.

Essentially, py + any pypi dep (didn't exhaustively try, but used 3+ unrelated ones) causes py to sometimes appear twice in lockfile.

I think, but don't know, this has to do with purls that get added when using pypi deps.

  purls:
  - pkg:pypi/py
  - pkg:pypi/apipkg
  - pkg:pypi/iniconfig

These don't appear to be sorted, and different re-generations of lockfile will cause these to be in different orders.

And the times I see 2 versions of py in packages, they appear to have their purls sorted differently:

- kind: conda
  name: py
  version: 1.11.0
  build: pyh6c4a22f_0
  subdir: noarch
  noarch: python
  url: https://conda.anaconda.org/conda-forge/noarch/py-1.11.0-pyh6c4a22f_0.tar.bz2
  sha256: 268be33a290e3d51467ab29cbb5a80cf79f69dade2f2dead25d7f80d76c3543a
  md5: b4613d7e7a493916d867842a6a148054
  depends:
  - python >=2.7
  license: MIT
  license_family: MIT
  purls:
  - pkg:pypi/py
  - pkg:pypi/apipkg
  - pkg:pypi/iniconfig
  size: 76038
  timestamp: 1636301988765
- kind: conda
  name: py
  version: 1.11.0
  build: pyh6c4a22f_0
  subdir: noarch
  noarch: python
  url: https://conda.anaconda.org/conda-forge/noarch/py-1.11.0-pyh6c4a22f_0.tar.bz2
  sha256: 268be33a290e3d51467ab29cbb5a80cf79f69dade2f2dead25d7f80d76c3543a
  md5: b4613d7e7a493916d867842a6a148054
  depends:
  - python >=2.7
  license: MIT
  license_family: MIT
  purls:
  - pkg:pypi/iniconfig
  - pkg:pypi/py
  - pkg:pypi/apipkg
  size: 76038
  timestamp: 1636301988765

I normally see a single string under purls (for other conda deps), so maybe just a case that has not been accounted for yet.

Expected behavior

I would expect a single instance of py when it is the exact same dep (ie https://conda.anaconda.org/conda-forge/noarch/py-1.11.0-pyh6c4a22f_0.tar.bz2).

This sometimes causes minor annoyances when merging branches, and the lines have changed for this dep.

@fpaniagua fpaniagua added the bug Something isn't working label May 10, 2024
baszalmstra added a commit to mamba-org/rattler that referenced this issue May 23, 2024
* Turns `purls` into a BtreeSet to ensure consistent ordering (fixes
prefix-dev/pixi#1367)
* Removed `Ord` and `PartialOrd` from `PackageRecord`. It doesnt make
sense.
* Bumped `resolvo` to remove `Ord` constraint from `Version`. 
* Conversion from `CondaPackage` and `PypiPackage` to Package.
* The ability to add packages to the lock file builder from another
environment.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant