4 ms·

Congrats! > Similarly, uv does not yet generate a platform-agnostic lockfile. This matches pip-tools, but differs from Poetry and PDM, making uv a better fit f

by epage 3y ago

Congrats! > Similarly, uv does not yet generate a platform-agnostic lockfile. This matches pip-tools, but differs from Poetry and PDM, making uv a better fit for projects built around the pip and pip-tools workflows. Do you expect to make the higher level workflow independent of requirements.txt / support a platform-agnostic lockfile? Being attached to Rye makes me think "no". Without being platform agnostic, to me this is dead-on-arrival and unable to meet the "Cargo for Python" aim. > uv supports alternate resolution strategies. By default, uv follows the standard Python dependency resolution strategy of preferring the latest compatible version of each package. But by passing --resolution=lowest, library authors can test their packages against the lowest-compatible version of their dependencies. (This is similar to Go's Minimal version selection.) > uv allows for resolutions against arbitrary target Python versions. While pip and pip-tools always resolve against the currently-installed Python version (generating, e.g., a Python 3.12-compatible resolution when running under Python 3.12), uv accepts a --python-version parameter, enabling you to generate, e.g., Python 3.7-compatible resolutions even when running under newer versions. This is great to see though! I can understand it being a flag on these lower level, directly invoked dependency resolution operations. While you aren't onto the higher level operations yet, I think it'd be useful to see if there is any cross-ecosystem learning we can do for my MSRV RFC: https://github.com/rust-lang/rfcs/pull/3537 https://github.com/rust-lang/rfcs/pull/3537 How are you handling pre-releases in you resolution? Unsure how much of that is specified in PEPs. Its something that Cargo is weak in today but we're slowly improving.

OJFord 3y ago
That is great. Fuzzing would be cool too - just completely randomise the versions within the claimed compatibility constraints.
charliermarsh 3y ago
Thanks Ed! Your work as always is a big source of inspiration. > Do you expect to make the higher level workflow independent of requirements.txt / support a platform-agnostic lockfile? Being attached to Rye makes me think "no". Yes, we absolutely do. We don't do this today, the initial scope is intentionally limited. But in the next phase of the project, we want to extend to multi-platform and multi-version resolution. > How are you handling pre-releases in you resolution? Unsure how much of that is specified in PEPs. Its something that Cargo is weak in today but we're slowly improving. This is something we talked with Jacob about quite a bit. Turns out (as you know) it's a very hard problem. For the initial release, we added a constraint: our default behavior is that if you want to use a pre-release, you _have_ to specify the package as a first-party dependency and use a pre-release marker in the version specifier. (We also support globally enabling and disabling pre-releases.) So, we basically don't support "transitive" pre-releases right now -- but we give you a dedicated error message if your resolution fails for that reason.
- thaliaarchi 3y ago
  Any plans to tackle the Python version installation side of things and make it as seamless as rustup has? I've previously used `pyenv install` for this, but it would be nice to fold it into one tool.
  - charliermarsh 3y ago
    Yeah, this is very much on our roadmap and probably one of the first things we'll tackle next.
  - rat87 3y ago
    Note that rye already handles it better then pyenv (it downloads pre built pythons instead of building from source). I assume they'll eventually they'll copy/move the functionality over.
woodruffw 3y ago
> How are you handling pre-releases in you resolution? Unsure how much of that is specified in PEPs. The living version of PEP 440 has a bit on how pre-releases are handled[1]. The basic version is that the installer shouldn't select them at all, unless the user explicitly indicates that they want a pre-release. Once opted into, they're ordered by their phase (alpha, beta, rc) and pre-release increment (e.g. `.beta.1 > `.alpha.2`). [1]: https://packaging.python.org/en/latest/specifications/version-specifiers/#handling-of-pre-releases https://packaging.python.org/en/latest/specifications/versio...
techwizrd 3y ago
PyTorch doesn't work well with platform-agnostic lockfiles. It's a constant source of issues for me when using Poetry.
- jvolkman 3y ago
  The vast majority of pypi packages are not PyTorch, however.

by epage 3y ago

OJFord 3y ago

That is great. Fuzzing would be cool too - just completely randomise the versions within the claimed compatibility constraints.

charliermarsh 3y ago

Thanks Ed! Your work as always is a big source of inspiration. > Do you expect to make the higher level workflow independent of requirements.txt / support a platform-agnostic lockfile? Being attached to Rye makes me think "no". Yes, we absolutely do. We don't do this today, the initial scope is intentionally limited. But in the next phase of the project, we want to extend to multi-platform and multi-version resolution. > How are you handling pre-releases in you resolution? Unsure how much of that is specified in PEPs. Its something that Cargo is weak in today but we're slowly improving. This is something we talked with Jacob about quite a bit. Turns out (as you know) it's a very hard problem. For the initial release, we added a constraint: our default behavior is that if you want to use a pre-release, you _have_ to specify the package as a first-party dependency and use a pre-release marker in the version specifier. (We also support globally enabling and disabling pre-releases.) So, we basically don't support "transitive" pre-releases right now -- but we give you a dedicated error message if your resolution fails for that reason.

thaliaarchi 3y ago
Any plans to tackle the Python version installation side of things and make it as seamless as rustup has? I've previously used `pyenv install` for this, but it would be nice to fold it into one tool.
- charliermarsh 3y ago
  Yeah, this is very much on our roadmap and probably one of the first things we'll tackle next.
- rat87 3y ago
  Note that rye already handles it better then pyenv (it downloads pre built pythons instead of building from source). I assume they'll eventually they'll copy/move the functionality over.

woodruffw 3y ago

> How are you handling pre-releases in you resolution? Unsure how much of that is specified in PEPs. The living version of PEP 440 has a bit on how pre-releases are handled[1]. The basic version is that the installer shouldn't select them at all, unless the user explicitly indicates that they want a pre-release. Once opted into, they're ordered by their phase (alpha, beta, rc) and pre-release increment (e.g. `.beta.1 > `.alpha.2`). [1]: https://packaging.python.org/en/latest/specifications/version-specifiers/#handling-of-pre-releases https://packaging.python.org/en/latest/specifications/versio...

techwizrd 3y ago

PyTorch doesn't work well with platform-agnostic lockfiles. It's a constant source of issues for me when using Poetry.

jvolkman 3y ago
The vast majority of pypi packages are not PyTorch, however.