Enables explicit root setting for [tool.rye.workspace] table

[bnorick]

Problem

Wanted to take a crack at solving my specific problem in #856. Repeated here:

In a monorepo I am working on, there is the following structure:

monorepo
  project0
  project1 ← project0
  project2 ← project0

Each project should be usable independently and their dependencies may conflict (so a top level workspace does not apply). I would like for users of the repo to be able to rye sync in monorepo/project1 when they need to work on that project and have an editable install of monorepo/project0.

Above I only showed a single dependencies per project, but in the future there may be more than one dependency from the monorepo for a given project, e.g., project4:

monorepo
  project0
  project1 ← project0
  project2 ← project0
  project3
  project4 ← project0, project3

Solution

By setting the root key in the [tool.rye.workspace] table one can now explicitly override the search root for projects for the relevant project's workspace. Project membership (i.e., is_member) is first checked as before, using the current project's root, and then is checked using the explicitly specified search root (if applicable).

This might not be the final answer (e.g., it might be nice to be able to control the search root on a per member basis, where members could optionally become inline tables with name (the current glob pattern) and root keys), but it's a good starting point.

Given this is my first time looking at the rye code base, and my Rust is not expert level, I'd appreciate feedback here. I left a TODO related to error handling in the case when the root key results in an Error.

Happy to hear discussion about this PR, it solves my problem for the moment so I hope we can get in it rye in some form in the near future because I can't use it in my project until there is some way to handle this scenario.

[bnorick]

I made a quick demo repo to show this structure. You can also check this diff to see the difference the proposed PR makes compared with rye 0.32.0 in the simple scenario described above. Namely, it correctly adds the -e file:../project0 requirements and imports work as expected.

I also ran make test and saw no issues.

[enkhjile]

I also have a monorepo project with a similar structure and would love this kind of feature

[pvardanis]

That would be great as a feature! I also work on a mono repo where I have local dependencies, that must be used in separate environments because of dependency conflicts.

[ydennisy]

@bnorick this looks like a great feature, do you know if the maintainers plan to merge this PR?

[pvardanis]

@zanieb any plans to merge this one?

[bnorick]

I've shifted to uv entirely, going to close this PR now.

[pvardanis]

@bnorick does uv support this so we can have a monorepo but different venvs per project in the workspace?

[bnorick]

It sure does, works great in my even moderately complex monorepos. I put a simple example in bnorick/uv-monorepo-examples and I may add more complex examples in the future.