-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
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). |
The value of 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 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. |
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?The text was updated successfully, but these errors were encountered: