Open mmerickel opened 6 months ago
This may be a problem with uv
https://github.com/astral-sh/uv/issues/1661. Have you tried it in the latest version of rye?
@ischaojie rye 0.31.0 exhibits the same issue - I think this is very specific to build-system.requires
- I don't have problems with just normal (dev-)dependencies between projects in the workspace. The updated error outputs the following:
❯ rye sync
Reusing already existing virtualenv
Generating production lockfile: /Users/luser/scratch/rye-test/requirements.lock
error: Failed to build editables
Caused by: Failed to build editable: file:///Users/luser/scratch/rye-test/src/my-app
Caused by: Failed to install requirements from build-system.requires (resolve)
Caused by: No solution found when resolving: setuptools, wheel, my-setuptools-extension
Caused by: Because my-setuptools-extension was not found in the package registry and you require my-setuptools-extension, we can conclude that the requirements are unsatisfiable.
error: could not write production lockfile for workspace
Caused by:
Failed to run uv compile /var/folders/0b/gyxh16fx56d7hd_nqbxj1mxc0000gp/T/.tmp5aChR2/requirements.txt. uv exited with status: exit status: 2
This should be addressed upstream in the latest release of uv (0.1.27).
This should be addressed upstream in the latest release of uv (0.1.27).
@zanieb This issue is still there in the latest rye 0.33 which is using uv 0.1.37.
Yeah I don't think we support this. I don't know how we would know to find my-setuptools-extension
locally.
Just to say it (ignoring the implementation details and philosophies of rye/uv) - it's in the configured workspace so it could be found. Since it's a build-system dependency instead of a runtime dependency I think conceptually it'd require an initial pass of the workspace to find package names + build dependencies prior to actually building each package, then properly sorting packages so they are built in the right order with respect to build dependencies.
Something similar would be required if build dependencies were supported in lockfiles which I don't think they are right now - correct me if I'm wrong.
Anecdotally here is how I do this without rye:
$ uv pip install -U pip
$ .venv/bin/pip wheel \
-w .venv/wheels \
-r requirements/01-setup.in -c requirements/01-setup.txt
$ uv pip install \
--color always \
--find-links .venv/wheels \
--refresh \
--reinstall \
-r requirements/02-src.in -c requirements/02-src.txt \
-r requirements/03-dev.in -c requirements/03-dev.txt
We use pip-tools to lock a 01-setup, then build wheels of those into a wheelhouse. Then that wheelhouse is used via --find-links
when building the packages that depend on those special build-time dependencies. This strategy also allows us to lock the versions of packages used at build time like setuptools.
edit I had to update this to use --refresh
as well because build dependencies are cached by default so updates to the setup dependencies that pip wheel
generated were not being used later via uv pip install
if the version number on the wheel didn't change (which it doesn't when those are editable dependencies in the workspace).
A workspace would help a lot here to avoid needing the --refresh
and all of its gotchas/implications.
Steps to Reproduce
pyproject.toml
src/my-setuptools-extension/pyproject.toml
src/my-app/pyproject.toml
src/my-app/setup.py
This step is optional and here for completeness.
Expected Result
The workspace should support
build-system.requires
such that it is built and made available for other packages in the workspace to use.Actual Result
Rye isn't solving this problem and assuming the requirements are in a remote registry.
Version Info
Additional info
In our current repo, we do this by running a specific build step plus find-links: