Konubinix' opinionated web of thoughts

Install_requires (Setup.py) vs Requirements Files

fleeting

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

https://caremad.io/posts/2013/07/setup-vs-requirement/

no url or filesystem where you can fetch these dependencies from

https://caremad.io/posts/2013/07/setup-vs-requirement/

call these “abstract dependencies”

https://caremad.io/posts/2013/07/setup-vs-requirement/

Think of it like duck typing your dependencies, you don’t care what specific “requests” you get as long as it looks like “requests”.

https://caremad.io/posts/2013/07/setup-vs-requirement/

you want the same version to install in production as you developed and tested with locally.

https://caremad.io/posts/2013/07/setup-vs-requirement/

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.

https://caremad.io/posts/2013/07/setup-vs-requirement/

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.

https://caremad.io/posts/2013/07/setup-vs-requirement/

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.

https://caremad.io/posts/2013/07/setup-vs-requirement/