Add `--no-editable` to `uv pip install`

[kkpattern]

Summary

We have a workspace monorepo structured like this:

monorepo
    |- packages
          |- package_a
          |- package_b
          |- package_c

Package package_a depends on package_b, and package_bhas no workspace dependencies.

When building a Docker image with package_a installed, we want to install package_a and its dependency package_b into the system Python environment, and then remove the monorepo source code from the Docker image to reduce its size:

COPY . /tmp/monorepo
WORKDIR /tmp/monorepo
RUN uv pip install --system packages/package_a
RUN rm -r /tmp/monorepo

However, uv pip install currently installs workspace dependencies as editable, and there is no --no-editable option for uv pip install.

Therefore, if we remove the /tmp/monorepo directory, importing package_b fails because its source code is gone.

It would be nice if we could have a --no-editable flag for uv pip install, similar to the one available for uv sync.

Thanks.

Example

No response

[viniciuscr]

I am having the exactly same issue. I am trying to create a bundle to deploy to a aws lambda, basically using uv export and uv pip install. however the uv pip install creates a .pth file point the my workspace project, instead of copying it source to the dist/ location. it becomes nonviable to scale up a project that depends on multiple workspace projects.

[konstin]

@viniciuscr Can you use --no-editable with uv export instead of uv pip install?

[viniciuscr]

@viniciuscr Can you use --no-editable with uv export instead of uv pip install?

I use it, but as @kkpattern explains, it works only for the target package, not to its dependencies. My command is uv export --frozen --no-dev --no-editable --quiet --package $(PACKAGE) -o dist/$(PACKAGE)/requirements.txt

the next step would be

uv pip install \
		--no-installer-metadata \
		--no-compile-bytecode \
		--python-platform x86_64-manylinux2014 \
		--target dist/$(PACKAGE) \
		--exact \
		--strict \
		-r dist/$(PACKAGE)/requirements.txt

but since uv pip install does not have the --no-editable option it creates a .pth file pointing to the workspace project.

I tested the sync command , and the --no-editable is indeed the missing part. uv sync will have the same behavior of uv install: editable will have a .pth point to it, passing --no-editable uv sync will copy the code and dont create the .pth file. Which is the necessary behavior for uv pip install, in order to become viable to use it to create a deployment zip file to send to a lambda.

[konstin]

Can you share a minimal example for an input where uv export --no-editable exports an editable? We may still add --no-editable to uv pip install, but the uv export behavior sounds like a bug.

[viniciuscr]

Here I have the output from uv export

# This file was autogenerated by uv via the following command:
#    uv export --frozen --no-dev --no-editable --package project_a -o dist/project_a/requirements.txt
./handlers/project_a
./libs/project_b

Something I also tried was to use uv pip compile and to my surprise:

# This file was autogenerated by uv via the following command:
#    uv pip compile dist/project_a/requirements.txt
-e ./libs/project_b
    # via
    #   -r dist/project_a/requirements.txt
    #   project_a
./handlers/project_a
    # via -r dist/project_a/requirements.txt

An important info: both project where generated using uv init --package. As I plan to publish both

[badrobit]

I can also confirm we are seeing the same behavior that no matter what we try it cannot work with just the uv pip install

We did find a messy (and likely long term error prone workaround), we basically have two steps one to install the monorepo via the usual uv export and then uv pip install <requirements> we then add a follow on steps for:

uv pip install dist/project_b*.whl

(stealing the example provided by others) If you do a second uv pip install and point to a build wheel file you will get the same as if the dependent library had been installed as non-editable in the first place. I don't think I can sell this as sustainable as this depends on no additional dependencies being added and will explode our .justfiles to account for the bug.

[MKLeb]

We have found a solution to this by utilizing the --no-deps flag on the uv pip install and the --no-editable flag on uv export. This is currently working in our monorepo setup, and local dependencies are being installed as expected in their target virtual environment (in this example, foo/packages).

uv export --package foo --frozen --no-default-groups --no-editable -o requirements.txt
uv pip install --no-deps --no-installer-metadata --target foo/packages -r requirements.txt

uv export should capture all dependencies already, thus the --no-deps optional is valid.

[viniciuscr]

We have found a solution to this by utilizing the --no-deps flag on the uv pip install and the --no-editable flag on uv export. This is currently working in our monorepo setup, and local dependencies are being installed as expected in their target virtual environment (in this example, foo/packages).

uv export --package foo --frozen --no-default-groups --no-editable -o requirements.txt uv pip install --no-deps --no-installer-metadata --target foo/packages -r requirements.txt

uv export should capture all dependencies already, thus the --no-deps optional is valid.

the --no-deps works for me. I just think the hole thing is a little confusing.

[mlnrt]

Same here the --no-deps in uv pip install works for me, and I also find it confusing