Allow for using `rye lock` without a python install

astral-sh / rye

a Hassle-Free Python Experience

https://rye.astral.sh

MIT License

13.46k stars 460 forks source link

Allow for using `rye lock` without a python install #1221

Open Chippiewill opened 2 months ago

Chippiewill commented 2 months ago

Currently rye lock will create a virtualenv if it doesn't exist, even though it doesn't strictly need to. This is because it's a wrapper around rye sync which installs the locked packages into the virtualenv - and rye lock essentially just disables the package install after the lock file has been updated.

Additionally it installs the required version of python if it doesn't exist, which it would also not require unless pip-tools is being used for locking rather than uv.

There are certain use cases (such as when updating lockfiles with tools like Renovate) where it would be desirable to update the lockfiles without pulling in unnecessary stuff: https://github.com/renovatebot/renovate/issues/25273 - there are workarounds to avoid pulling down python (such as pre-registering the toolchain), but this is clunky and a bit fragile.

Chippiewill commented 2 months ago

I'd be happy to have a go at implementing this (should it be deemed a sensible idea), but I'd need some pointers about how best to approach it. The rye sync command looks like it wasn't originally written with the uv tool in mind so it makes assumptions about the necessity of Python and a virtualenv early, and often.

For example the py_ver that's passed down into uv/pip-tools is an output from the function that installs the correct python version (which might subtly change the version) https://github.com/astral-sh/rye/blob/main/rye/src/sync.rs#L163 - refactoring uv sync to not require Python could be non-trivial.

charliermarsh commented 2 months ago

We'd need to start by supporting this in uv -- uv currently requires a Python installation in order to resolve and install. But you're right that, in theory, we could support resolution without a Python installation. However, there would be a bunch of limitations:

It would have to imply --only-binary, because you can't build any packages from source without a Python installation. So all of your dependencies would need to have wheels available.
It would have to imply --universal, because without a Python installation, we can't know what Python platform you're targeting.

vhdirk commented 1 month ago

For completeness sake, this idea has also been proposed here: https://github.com/containerbase/base/pull/2684#issuecomment-2217381056