Fix: uv tool install installs workspace members non‑editable by default; --editable to opt‑in#16335
Fix: uv tool install installs workspace members non‑editable by default; --editable to opt‑in#16335krishmas wants to merge 11 commits intoastral-sh:mainfrom
Conversation
|
Hi @zanieb , would it be possible to get a review here? 🙏 |
|
I spent a bit of time exploring an alternative (mostly guiding Claude) and was considering something more of the flavor here https://github.com/astral-sh/uv/compare/zb/tool-workspace I'm not sure which is best yet, I'll try to find time to look closer but my time is elsewhere right now. |
|
Hi @zanieb , just wanted to ping again - anything I can do to help out here? |
|
@zanieb just bumping this again - lmk your thoughts. Happy to stop pinging if this is still something you want to think about more before merging this in. |
|
I haven't had a chance to look further. I'm pretty sure the approach in #16335 (comment) makes more sense, but maybe @konstin can confirm he agrees before you pursue that? |
|
The approach in https://github.com/astral-sh/uv/compare/zb/tool-workspace makes more sense to me: We should decide before doing the resolution if the default for workspace packages should be editable or non-editable, instead of changing this after the resolution is done. There's also the question whether we want to expose inheriting the workspace editable state to users (like |
Summary
Resolves #16306
Test Plan
tool_install::tool_install_no_editable_workspace_member):tool_install::tool_install_workspace_editable):uv tool install ./project#16306 and observed that changes to workspace dependency source code no longer changed tool behavior unless--editablewas used