Python Packaging for Developers in a Hurry
giovannipcarvalho.github.io
giovannipcarvalho.github.io
Managing dependencies
"If you’re developing a library, use nothing. Let your users decide, and give them as much flexibility as possible to maximize compatibility (don’t pin, unless to exclude some known-to-fail version ranges)." What does this "nothing" contain? :-) A `requirements.txt`? Do you test the library with various versions of that dependency (e.g. with tox)?
I mean you don't need pinned dependencies. Just declare the dependencies as you would normally in install_requires (from setup.cfg) and that's it. No need for pinning exact dependency versions with pip-tools, therefore no requirements.txt.
I think the standard practice is to just test the library against the latest version of its dependencies. In the case a new release of a dependency causes breakage, then you update your install_requires to restrict the version.
"Using a virtual environment inside a Docker container is perhaps over-the-top, but it provides extra isolation from the base image’s own Python dependencies, and the entire /venv folder can be copied over between stages if you need."
Do you have some use cases in mind when this can be handy?
You can apt install gcc in a build stage, install your dependency and then you don't need to bother clearing apt lists cache, pruning unneeded packages such as gcc and the packages that were installed alongside it, etc.
Then, you create another stage for the final production runtime, copy the entire virtual environment over and that's it.
In short, the virtual environment is easier to transport from one stage to another, compared to a non-isolated environment -- and that makes it easy to trim down the image size.