3 ms·
For your dependency/versioning issue, use a virtualenv per-project and pin your dependency versions in requirements.txt
by _bohm 4y ago
For your dependency/versioning issue, use a virtualenv per-project and pin your dependency versions in requirements.txt
- LtWorf 4y agoDon't pin unless it's needed. I have a library… most downloaded version is 3 years old. The newer versions are massively faster but nobody uses them.
- anderskaseorg 4y agoYou should not pin the public requirements that get uploaded with a library (listed in setup.py, setup.cfg, or pyproject.toml), since that will restrict your downstream users, leading to version conflicts and persistent security vulnerabilities. But it’s totally reasonable to pin the private requirements that you develop it against (listed in requirements.txt, poetry.lock, or similar), updating them every so often during the course of development, so that contributors can use a consistent set of tools.
- LtWorf 4y agoSo leaf packages can pin vulnerable or slow stuff why?
- anderskaseorg 4y agoThe context is > For your dependency/versioning issue, use a virtualenv per-project and pin your dependency versions in requirements.txt requirements.txt is not uploaded to PyPI and has no effect on your package’s dependencies when a user installs it (leaf package or no). It’s only used for developing the package itself, typically in a unique virtual environment.
- _bohm 4y agoAgree in principle, but I'm giving advice to someone who programs on occasion and is primarily concerned with their programs breaking due to dependency version upgrades when they come back to them after a little while.
- LtWorf 4y agoMy advice would be to use stuff that is in distributions… it hopefully (not necessarily) is maintained by less noob people who don't break API all the time.