Support tool.uv.workspace.default-packages
#3625
Labels
preview
Experimental behavior
Comments
too.uv.workspace.default-packagetool.uv.workspace.default-package
konstin
added a commit
that referenced
this issue
May 28, 2024
Add workspace support when using `-r <path>/pyproject.toml` or `-e <path>` in the pip interface. It is limited to all-editable static-metadata workspaces, and tests only include a single main workspace, ignoring path dependencies in another workspace. This can be considered the MVP for workspace support: You can create a workspace, you can install from it, but some options and conveniences are still missing. I'll file follow-up tickets (support in lockfiles, support path deps in other workspace, #3625) There is also support in `uv run`, but we need #3700 first to properly support using different current projects in the bluejay interface, currently the resolution and therefore the lockfile depends on the current project. I'd do this change first (it's big enough already), then #3700, and then add workspace support properly to bluejay. Fixes #3404
tool.uv.workspace.default-packagetool.uv.workspace.default-packages
tool.uv.workspace.default-packagestool.uv.workspace.default-package
tool.uv.workspace.default-packagetool.uv.workspace.default-packages
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When running commands such as
uv runoruv pip install -e .in the root of a virtual workspace, we currently error because we don't know which package to install. Similar cargo, we should allow declaring a default target, in this case a package rather than a bin, as:The text was updated successfully, but these errors were encountered: