3 ms·

pip+venv mostly work fine for me, but there are some libraries like say numpy/scipy that are heavy so I want to share them across projects instead of installing

pip+venv mostly work fine for me, but there are some libraries like say numpy/scipy that are heavy so I want to share them across projects instead of installing multiple copies. I use pyenv to create a python version separate from the system version and install global dependencies into that. It's been useful for that and is just a nice way to manage multiple versions of python. So pyenv is a great addition to the traditional pip+venv setup. unrelated rant - Why is the "requirements.txt" file a stupid flat listing of all transitive dependencies with pinned versions? It makes it harder to change library versions even if there are no true conflicts. I've resorted to making an "actual_requirements.txt" file manually listing only direct dependencies and whatever version constraints make sense. I wish pip would fix this.

akurtzhs 3y ago
> I've resorted to making an "actual_requirements.txt" file manually listing only direct dependencies and whatever version constraints make sense. Pip-tools has an elegant solution for this. You write an requirements.in where you list packages and optionally versions, then pip-compile turns that into a requirements.txt with every package including dependencies specified by versions. You can use it to update specific packages as well.
globular-toast 3y ago
> Why is the "requirements.txt" file a stupid flat listing of all transitive dependencies with pinned versions? It makes it harder to change library versions even if there are no true conflicts. My friend, here is what you seek: https://github.com/jazzband/pip-tools https://github.com/jazzband/pip-tools requirements.txt is flat because it's really the output of `pip freeze`. It's supposed to completely and exactly rebuild the environment. Unfortunately it's far too flexible and people abuse it by putting in only direct dependencies etc. If you're writing packages, you don't need a requirements.txt at all, by the way. Package dependencies (only direct dependencies) live in pyproject.toml with the rest of the package config. requirements.txt (and pip tools) are only for when you want to freeze the whole environment, like for a server deployment.

akurtzhs 3y ago

> I've resorted to making an "actual_requirements.txt" file manually listing only direct dependencies and whatever version constraints make sense. Pip-tools has an elegant solution for this. You write an requirements.in where you list packages and optionally versions, then pip-compile turns that into a requirements.txt with every package including dependencies specified by versions. You can use it to update specific packages as well.

globular-toast 3y ago

> Why is the "requirements.txt" file a stupid flat listing of all transitive dependencies with pinned versions? It makes it harder to change library versions even if there are no true conflicts. My friend, here is what you seek: https://github.com/jazzband/pip-tools https://github.com/jazzband/pip-tools requirements.txt is flat because it's really the output of `pip freeze`. It's supposed to completely and exactly rebuild the environment. Unfortunately it's far too flexible and people abuse it by putting in only direct dependencies etc. If you're writing packages, you don't need a requirements.txt at all, by the way. Package dependencies (only direct dependencies) live in pyproject.toml with the rest of the package config. requirements.txt (and pip tools) are only for when you want to freeze the whole environment, like for a server deployment.