Skip to content
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

uv sync groups from workspace member packages in a virtual workspace #8722

Closed
drmason13 opened this issue Oct 31, 2024 · 2 comments · Fixed by #8734
Closed

uv sync groups from workspace member packages in a virtual workspace #8722

drmason13 opened this issue Oct 31, 2024 · 2 comments · Fixed by #8734
Assignees
Labels
bug Something isn't working

Comments

@drmason13
Copy link

uv 0.4.29

I have a virtual workspace. I want to install a union of all my members' dependencies including development dependencies.

With dependency-groups I had hoped this would now be easy:

uv sync --group dev
error: Group `dev` is not defined in the project's `dependency-group` table

but this simply complained saying that no group dev existed in the workspace root (which is true, but I do have a dependency-group named dev in one of my members).

I've tried two approaches to workaround this:

  1. Move all dev dependencies into the workspace root
  2. Duplicate all dev dependencies in workspace root and each member package

Both have downsides, in the case of 1. (moving), my packages can no longer be tested independently since they lack their own development dependencies. In the case of 2. (duplicating), that is its own downside. To add development dependencies I am editing multiple pyproject.toml files, which is the kind of thing I hoped to avoid by using a virtual workspace.

Suggested solution

Within a virtual workspace, I want uv sync to have visibility of each members' dependency-groups specified within pyproject.toml, as well as their dependencies.

How to request that those groups be included or not could go one of two ways:

1. Implicit

  • Have uv sync --group dev include dependencies from all members' dependency groups, and the root.

2. Explicit

  • Have uv sync --group dev only see groups in the root project (behaviour unchanged).
  • Have uv sync --group dev --include-dependency-groups-of-all-workspace-members include dependencies from all members' dependency groups, and the root. Same as in the implicit case.

--include-dependency-groups-of-all-workspace-members is obviously too long, pending a suitable alternative. I don't have a strong opinion on the name of the option. It could also/instead be a config file option.

With 2. it would be natural to extend the request to list specific members to include the group from, though that's harder to think of syntax for. i.e. I want group dev from members foo and bar where foo and bar are the package names of an arbitrary subset of my workspace members. I don't have a good use case for this myself though.

@drmason13
Copy link
Author

Actually, I have discovered another workaround to improve 1. Move all dev dependencies into the workspace root

I first uv sync --only-group dev to get all the development dependencies

because I have it so they are all listed in the virtual workspace pyproject.toml instead of the members. No members list any dev dependencies, which avoids duplication.

Then, uv run --package foo pytest which will additionally install foo and its dependencies but does not uninstall any dev dependencies. Previously this was a problem because I wanted to not have every other member installed while testing foo, but the --only-group dev option to uv sync fixes this 🙂

When testing the next package, I can uv sync --only-group dev again to effectively uninstall foo and its dependencies and revert back to just having dev dependencies. Then I uv run --package bar pytest and so on.

Note: running uv sync --package foo would lose all the root dev dependencies, so I can't ever do that (while testing) but when building, I will do exactly that and everything should work out great.

I think that removes the need for this feature, for me.

@charliermarsh charliermarsh self-assigned this Oct 31, 2024
@charliermarsh charliermarsh added the bug Something isn't working label Oct 31, 2024
@charliermarsh
Copy link
Member

Sorry yeah -- this is a bug. I actually just noticed it in a separate context. Will fix it now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants