Regression in solving behaviour? #1917
Comments
|
I'm experiencing a similar issue. I used to be able to install the spaces pypi package, now I have a very similar error as described by @znichollscr. The only thing is downgrading to 0.25.0 doesn't seem to fix the issue for me The following pyproject.toml reproduces the issue [project]
name = "test-spaces"
version = "0.1.0"
description = "test hf spaces"
requires-python = ">=3.10.0"
readme = "README.md"
dependencies = []
[tool.pixi.project]
channels = ["conda-forge"]
platforms = ["linux-64"]
[tool.pixi.pypi-dependencies]
test-spaces = { path = ".", editable = true }
[tool.pixi.dependencies]
pip = ">=24.2,<25"
[tool.ruff]
ignore = [
"F722", # Forward annotation false positive from jaxtyping. Should be caught by pyright.
]doing Full error pixi add spaces --pypi
× failed to solve the pypi requirements of 'default' 'linux-64'
├─▶ failed to resolve pypi dependencies
╰─▶ Because any of:
spaces<=0.3.0
spaces>=0.6.0,<=0.8.0
spaces>=0.9.0,<=0.9.1
spaces==0.10.0
depends on typing-extensions>=4.5.0,<5.0.0 and typing-extensions==72.2.0, we can conclude that any of:
spaces<=0.3.0
spaces>=0.6.0,<=0.8.0
spaces>=0.9.0,<=0.9.1
spaces==0.10.0
cannot be used.
And because only the following versions of spaces are available:
spaces<=0.3.0
spaces>=0.6.0,<=0.8.0
spaces>=0.9.0,<=0.9.1
spaces==0.10.0
spaces==0.11.0
spaces==0.12.0
spaces==0.13.0
spaces==0.14.0
spaces==0.15.0
spaces>=0.16.0,<=0.16.2
spaces>=0.16.3,<=0.23.2
spaces>=0.24.0,<=0.28.3
spaces>=0.29.0
we can conclude that any of:
spaces<0.11.0
spaces>0.11.0,<0.12.0
spaces>0.12.0,<0.13.0
spaces>0.13.0,<0.14.0
spaces>0.14.0,<0.15.0
spaces>0.15.0,<0.16.0
spaces>0.16.2,<0.16.3
spaces>0.23.2,<0.24.0
spaces>0.28.3,<0.29.0
cannot be used. (1)
Because any of:
spaces==0.11.0
spaces==0.12.0
spaces==0.13.0
spaces==0.14.0
spaces==0.15.0
spaces>=0.16.0,<=0.16.2
spaces>=0.16.3,<=0.23.2
spaces>=0.24.0,<=0.28.3
spaces>=0.29.0
depends on typing-extensions>=4,<5 and typing-extensions==72.2.0, we can conclude that any of:
spaces==0.11.0
spaces==0.12.0
spaces==0.13.0
spaces==0.14.0
spaces==0.15.0
spaces>=0.16.0,<=0.16.2
spaces>=0.16.3,<=0.23.2
spaces>=0.24.0,<=0.28.3
spaces>=0.29.0
cannot be used.
And because we know from (1) that any of:
spaces<0.11.0
spaces>0.11.0,<0.12.0
spaces>0.12.0,<0.13.0
spaces>0.13.0,<0.14.0
spaces>0.14.0,<0.15.0
spaces>0.15.0,<0.16.0
spaces>0.16.2,<0.16.3
spaces>0.23.2,<0.24.0
spaces>0.28.3,<0.29.0
cannot be used, we can conclude that all versions of spaces cannot be used.
And because you require spaces, we can conclude that the requirements are unsatisfiable.
hint: Pre-releases are available for spaces in the requested range (e.g., 0.29b7), but pre-releases weren't enabled (try:
`--prerelease=allow`)The important bit being depends on typing-extensions>=4.5.0,<5.0.0 and typing-extensions==72.2.0, we can conclude that any of:which like mentioned, doesn't make sense because there is not typing-extensions==72.2.0 it seems like in my case its typing-extensions that's blocking things. I also notice that if I don't include, things resolve fine. |
|
Hi @pablovela5620 and @znichollscr, I haven't looked at @znichollscr issue yet, but I'm kinda guessing its the same as @pablovela5620. It seems that our mapping is returning the incorrect mapping for setuptools. Where it incorrectly assumes its the same as the packages:
As you can see these are all 72.2.0 versions which is a setuptool version. So this is definitely a bug, I don't know why this is happening, (cc @nichmor) is more versed in the mapping. However, most of the team is attending EuroSciPy (and currently travelling), so I'll take a look later as well. |
|
hey! the bug was found - we extract mapping names also from site-packages/_vendor folder from setuptools which produces a wrong result ( as it can be seen here: https://conda-mapping.prefix.dev/hash-v0/0252f6570de8ff29d489958fc7826677a518061b1aa5e1828a427eec8a7928a4 ). I'm working on the fix which will be soon available |
|
I've tested both projects and they seem to work again for me, closing this issue, feel free to re-open if issue persists. |
|
Can confirm this has fixed my issue: climate-resource/input4mips_validation#67 Thanks for such a fast turnaround 🎉 |
and others
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
Take the following
pyproject.tomlfile, which comes from herepyproject.toml file
There are probably keys that aren't relevant in here, but for completeness I've included it all
With pixi 0.26.1, the solving passes
pixi 0.26.1 output
With pixi 0.27.0, the solving fails
pixi 0.27.0 output
With pixi 0.28.1 (latest at the time of writing), the solving also fails
pixi 0.28.1 output
Issue description
Thanks for all your work on pixi, it's an amazing tool.
All the details are in the above, but as a shorter summary. My pyproject.toml installs fine (with e.g.
pixi install -e all-dev) with pixi 0.26.1. However, with 0.27.0 and 0.28.1 (latest at the time of writing), the solving fails.As far as I can tell, pixi (or perhaps UV under the hood) isn't correctly handling the version of platformdirs. One of the lines in the output is,
And because virtualenv>=20.10.0,<=20.16.2 depends on platformdirs>=2,<3 and platformdirs==72.2.0, we can conclude that virtualenv>=20.10.0 cannot be used, which doesn't make sense to me because there is no platformdirs 72.2.0 anywhere (neither in thepyproject.tomlfile nor on PyPI).This may be releated to make #1295.
Expected behavior
I expected this to solve, even with the newer versions of pixi. This seems like a regression to me, but it is possible that I am missing something (if so, apologies and thanks for helping out).
The text was updated successfully, but these errors were encountered: