Install_requires (Setup.py) vs Requirements Files
Fleeting- External reference: http://packaging.python.org/discussions/install-requires-vs-requirements.html
- External reference: https://caremad.io/posts/2013/07/setup-vs-requirement/
- see,
install_requires is a setuptools setup.py keyword that should be used to specify what a project minimally needs to run correctly
— http://packaging.python.org/discussions/install-requires-vs-requirements.html
not considered best practice to use install_requires to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades.
— http://packaging.python.org/discussions/install-requires-vs-requirements.html
Requirements Files described most simply, are just a list of pip install arguments placed into a file
— http://packaging.python.org/discussions/install-requires-vs-requirements.html
Whereas install_requires defines the dependencies for a single project, Requirements Files are often used to define the requirements for a complete Python environment
— http://packaging.python.org/discussions/install-requires-vs-requirements.html
requirements files often contain an exhaustive listing of pinned versions for the purpose of achieving repeatable installations of a complete environment
— http://packaging.python.org/discussions/install-requires-vs-requirements.html
requirements files often contain pip options like –index-url or –find-links to make requirements “Concrete”, i.e. associated with a particular index or directory of packages. 1
— http://packaging.python.org/discussions/install-requires-vs-requirements.html
lot of misunderstanding between setup.py and requirements.txt and their roles
no url or filesystem where you can fetch these dependencies from
call these “abstract dependencies”
Think of it like duck typing your dependencies, you don’t care what specific “requests” you get as long as it looks like “requests”.
you want the same version to install in production as you developed and tested with locally.
You can fork a library, change the code, and as long as it has the right name and version specifier that library will happily go on using it.
Given a directory with a setup.py inside of it you can write a requirements file that looks like: –index-url https://pypi.python.org/simple/
-e . Now your pip install -r requirements.txt will work just as before. It will first install the library located at the file path . and then move on to its abstract dependencies, combining them with its –index-url option and turning them into concrete dependencies and installing them.
If your top level library still depends on just the name then you can install the development version when using the requirements.txt and the release version when not, using a file like: –index-url https://pypi.python.org/simple/
-e https://github.com/foo/bar.git#egg=bar -e . This will first install the bar library from https://github.com/foo/bar.git, making it equal to the name “bar”, and then will install the local package, again combining its dependencies with the –index option and installing but this time since the “bar” dependency has already been satisfied it will skip it and continue to use the in development version.