|
|
|
|
|
|
by thristian
3738 days ago
|
|
|
As somebody who deploys a lot of business-critical Python apps at $EMPLOYER, I don't even write a requirements.txt. During development and integration testing, I want to get the latest version of my dependencies that I should be compatible with, so I use SemVer matching (somepackage~=1.2.3) in setup.py. For deployment, I want to use the exact dependency packages that the code was tested against. So after automated testing is complete, it runs "pip wheel" to build wheels of my package and all its dependencies and put them into a directory, then that is the artefact I use to recreate the package in production. Much more reliable than requirement.txt, since it doesn't assume that PyPI or internet access is available, and it doesn't care if upstream authors silently update packages without changing the version number. The last scenario is unit-testing, because sometimes tests have extra dependencies the rest of the code doesn't share, like a mock library or other test helper. In theory, these extra things could be put in setup.py's "tests_require" option, but then they'd only be installed if you run tests with "python setup.py test", and they'd also be installed with "easy_install", which is terrible. I'm thinking maybe I should use setuptools' "feature" syntax, so you only get the test dependencies if you install with the [test] feature. |
|
|
You write a requirements.in text file where you list libraries by just their name, and then run "pip-compile requirements.in" and it will output a requirements.txt.
It also has a function called "pip-sync" which will then install/update everything in the requirements.txt file.
https://github.com/nvie/pip-tools