-
Notifications
You must be signed in to change notification settings - Fork 210
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
fix: improve version conversion #1201
Conversation
Thanks @wolfv ! I am not sure of what order of precedence we should have (if any). When I thought about it, it seemed more logical to me to let the solver handle various constraints, coming from various tables |
@olivier-lacroix that works, theoretically! Unfortunately calling |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from the python dependencies this looks good
src/project/manifest/pyproject.rs
Outdated
version_or_url_to_nameless_matchspec(&pythonspec).unwrap(), | ||
SpecType::Run, | ||
); | ||
if !target.has_dependency("python", Some(SpecType::Run)) || python_spec.is_some() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should not make the requires-python
be more important then the pixi one. This won't let the user overwrite it if they want a different version from what the build package is allowed to use. e.g.
requires-python = `>=3.7`
Will always give you the latest version but users might want to run their environment on 3.9
and then they can't overwrite that in the tool.pixi
section.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we also don't want a warning, in that case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so, it will get annoying fast. Possibly an tracing::info
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to not do anything for other interpreters? Pypy, etc…
Ah. Then indeed, I think it would make sense to have the pixi.dependency table take precedence over the require-python |
Great! Thanks @wolfv ! |
Just to note - this overrides the It would be a future improvement to take both constraints into account. |
Just, to make sure: The fact that I have this in the # cat pyproject.toml | grep "requires-python"
requires-python = "~= 3.11" But my "default" # pixi run python -V
Python 3.12.3 ...is an expected behavior? Do I need to add the same constraint to |
You should not need to. But the conversion between pypi & conda constraints is pretty simple at the moment. Basically, your |
This improves the logic a little bit.
Python versions like
==3.11.*
now get parsed to3.11.*
which works better for conda requirements.We warn the user if there is both a
requires-python
and apython
dependency in thetool.pixi.dependencies
section.We prefer the
requires-python
over a value in the pixi deps.cc @olivier-lacroix
fixes #1193