Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For your dependency/versioning issue, use a virtualenv per-project and pin your dependency versions in requirements.txt


Don'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.


You 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.


So leaf packages can pin vulnerable or slow stuff why?


The 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.


Agree 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.


My 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: