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

Support pip freeze --exclude-editable #2738

Closed
charlesnicholson opened this issue Mar 30, 2024 · 3 comments · Fixed by #2740
Closed

Support pip freeze --exclude-editable #2738

charlesnicholson opened this issue Mar 30, 2024 · 3 comments · Fixed by #2740
Labels
compatibility Compatibility with a specification or another tool

Comments

@charlesnicholson
Copy link

pip freeze --exclude-editable emits a requirements file that contains all packages installed in the venv, without the editable installs. This can be handy when shipping a bunch of wheels as a deployment, where the editable-installed source packages in the venv get wheeled and shipped with the frozen requirements file. That way you can ship the first-party wheels with a frozen manifest of all third-party wheels at the time the first-party wheels were created, and the venv can be deterministically recreated.

uv on main doesn't support this at time of writing; could it?

@hmc-cs-mdrissi
Copy link

This sounds very similar to unsafe-package flag and maybe adding a similar flag for pip freeze would resolve this usage. One common use case for --unsafe-package is to remove editable packages by name (or any other package needed outside of frozen file).

@charlesnicholson
Copy link
Author

charlesnicholson commented Mar 31, 2024

The value of --exclude-editable is that you don't have to name your packages. In our case it's much more work to collect the names of all of our python packages spread through our repo and submodules so that we can pass them as arguments to --exclude-editable. I'd much rather just call VIRTUAL_ENV=my_venv uv pip freeze --exclude-editable.

Also, the semantics feel different- we're not excluding our editable installations because they're "unsafe", we're excluding them so that we can get a perfect list of pinned versions of third-party packages that our packages depend on.

So, having --unsafe-package does also sound useful but it also feels like a different use case.

@hmc-cs-mdrissi
Copy link

hmc-cs-mdrissi commented Mar 31, 2024

Unsafe is just historical naming. The name history has to do with originally only fixed set of packages were excluded and users could not avoid emitting others. The code evolved from that but intent of excluding them is unrelated to “safety”. The flag’s actual purpose is solely way for user to specify exclusions. I can say this with confidence as I was one who implemented the original pip-compile flag. Uv also calls it separate name that doesn’t mention unsafe.

Yes it does require you to name all of your editables once. My own use case for that flag was solely to remove editables but instead of designing flag for very specific thing it was easier to make a broader flag that had that power.

@charliermarsh charliermarsh added the compatibility Compatibility with a specification or another tool label Mar 31, 2024
charliermarsh pushed a commit that referenced this issue Mar 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility Compatibility with a specification or another tool
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants