Add `--non-editable` to allow syncing with non-editable workspace members

[charliermarsh]

Do we want to support this?

[charliermarsh]

(It's very easy to do.)

[charliermarsh]

If no one objects I can add it, not too hard.

[zanieb]

I don't fully understand what this means. I worry how close the flag is to --no-editable.

[charliermarsh]

It would mean: install the project and any workspace members as non-editable. So, build them to sdists, and install them into the environment, rather than adding a .pth file.

[zanieb]

Hm. --no-editable-project? I'm not sure. Makes sense as something to support though. Seems easy to defer to after stabilization.

[eruvanos]

Hi,

I think I would need this flag, but maybe it is better to describe my use case, there might be another solution for it with uv:

I want to setup multiple AWS Lambda Functions, which all come with their own dependencies, some use flask, some don't, etc.

For local development it is convenient, to have one virtual environment, so I go with setting up a virtual workspace. I add multiple packages, one for each Lambda function.

I add one "shared" package, which I will use for code that is shared between all Lambdas.

I install the shared package into the other ones, which will create an entry like:

[tool.uv.sources]
shared = { workspace = true }

Next I create the Lambda artefact, by installing the package with --target

cd package_a
uv pip install -c ../uv.lock --target dist .

dist/ now contains everything I would have to ship, but the shared package is only referenced with .pth file, which will not work in the lambda environment.

From my point of view, --non-editable support in the uv pip install command could be used to fix this.

[pawamoy]

I would use such a flag, yes, for the project itself (I don't use workspaces (yet)). Apologies if this not what this issue is about.

The initial use-case (a few years ago) was for multi-stage Docker builds: install every deps + project in a first stage, copy in a later stage. Editable installs of the project would not be working once the venv was copied in the final stage, since the sources were not present anymore.

The current use-case is to make CI more robust (to spot packaging issues early), with something like this:

if [ -n "${CI}" ]; then
  uv sync --no-editable-project
else
  uv sync
fi

[orf]

This would be very useful when building docker images with workspaces - you would be able to do something akin to:

RUN --mount=bind,from=project,source=src/,target=src/ \
   --mount=type=bind,from=project,source=pyproject.toml,target=pyproject.toml \
   --mount=type=bind,from=project,source=uv.lock,target=uv.lock \
   uv sync --frozen

and avoid having to copy the src/ directory into the image at all, and avoid multi-stage builds that in essence just try and emuate the above.

[bachya]

@charliermarsh @zanieb Is there anything further the community could provide input on here? Noting that CM said this was relatively easy; this one feature is all that remains for us to move our large monorepo completely over to uv, so I'm excited to see it in action. I'd be happy to contribute if feedback/additional dialog would help drive a decision. No rush, of course—I'm sure many other priorities are going on.

(Unfortunately, my Rust is non-existent, and I'm not in a position to submit an actual PR. 🫠)

[charliermarsh]

I think I can take this one on soon. It’s mostly about figuring the right names / UX / concepts.