When to use pip requirements file versus install_requires in setup.py?

Question

I'm using pip with virtualenv to package and install some Python libraries.

I'd imagine what I'm doing is a pretty common scenario. I'm the maintainer on several libraries for which I can specify the dependencies explicitly. A few of my libraries are dependent on third party libraries that have transitive dependencies over which I have no control.

What I'm trying to achieve is for a pip install on one of my libraries to download/install all of its upstream dependencies. What I'm struggling with in the pip documentation is if/how requirements files can do this on their own or if they're really just a supplement to using install_requires.

Would I use install_requires in all of my libraries to specify dependencies and version ranges and then only use a requirements file to resolve a conflict and/or freeze them for a production build?

Let's pretend I live in an imaginary world (I know, I know) and my upstream dependencies are straightforward and guaranteed to never conflict or break backward compatibility. Would I be compelled to use a pip requirements file at all or just let pip/setuptools/distribute install everything based on install_requires?

There are a lot of similar questions on here, but I couldn't find any that were as basic as when to use one or the other or using them both together harmoniously.

Beth

This is very nice article explaining the relationship of the two, and also how they integrate. – Infinitesimal

Related: #14400034 – Himmler

Answer 1

My philosophy is that install_requires should indicate a minimum of what you need. It might include version requirements if you know that some versions will not work; but it shouldn't have version requirements where you aren't sure (e.g., you aren't sure if a future release of a dependency will break your library or not).

Requirements files on the other hand should indicate what you know does work, and may include optional dependencies that you recommend. For example you might use SQLAlchemy but suggest MySQL, and so put MySQLdb in the requirements file).

So, in summary: install_requires is to keep people away from things that you know don't work, while requirements files to lead people towards things you know do work. One reason for this is that install_requires requirements are always checked, and cannot be disabled without actually changing the package metadata. So you can't easily try a new combination. Requirements files are only checked at install time.

Swetiana

does this means you should mirror setup.py install_requires= deps in requirements.txt? – Fear

Having both, requirements in setup.py and a requirements file is dangerous though, because the duplication just asks to become out of sync. – Strut

Also, how do you actually work with it then? I'd assume, you use the requirements file once to get to a state that is definitely working. Then install with the actual package with pip. You'll never be able to use -U because that might override the dependencies from the requirements file? How do you upgrade? – Strut

Does this answer apply equally to applications and packages? Imagine my-web-app (an app) depending on some-tool (a package), both of which depend on the requests package. If some-tool has a requirements.txt file that pins a particular version or version range of requests, that would seem to create a potential problem for my-web-app, which might have specified a conflicting version/version range. – Perak

There should be only way to install a package. So having both is not recommended unless you want to confuse other contributors. – Arrant

This answer is confusing. Why would I bloat my requirements.txt file with packages that are not needed? – Scheme

Answer 2

here's what I put in my setup.py:

# this grabs the requirements from requirements.txt
REQUIREMENTS = [i.strip() for i in open("requirements.txt").readlines()]

setup(
    .....
    install_requires=REQUIREMENTS
)

Apfelstadt

Watch out, requirements files could contain comments and inclusions. You should use the pip parser – Wildeyed

yes, I eventually changed this to strip out comments. pip parser looks better than my answer. – Apfelstadt

Why use a requirements file at all if all it contains is already in setup.py? – Strut

@RomainHardouin, as mentioned in comments to your linked answer, pip isn't meant to be used that way. – Joinder

yeah this worked for me until a critical --extra-index-url in in the requirements was required and this blew up in my face. Thanks @RomainHardouin – Goyette

Very cool but did not solve my problem of mixed pypi and artifactory requirements. – Paralyse

I cannot manage to open this file when running "python -m build", requirements.txt is not found because the script is not run directly in the current folder (and file is not defined either) – Yoho

Answer 3

The Python Packaging User Guide has a page about this topic, I highly recommend you read it:

• install_requires vs requirements files

Summary:

install_requires is there to list the dependencies of the package that absolutely must be installed for the package to work. It is not meant to pin the dependencies to specific versions, but ranges are accepted, for example install_requires=['django>=1.8']. install_requires is observed by pip install name-on-pypi and other tools.

requirements.txt is just a text file, that you can choose to run pip install -r requirements.txt against. It's meant to have versions of all dependencies and subdependencies pinned, like this: django==1.8.1. You can create one using pip freeze > requirements.txt. (Some services, like Heroku, automatically run pip install -r requirements.txt for you.) pip install name-on-pypi does not look at requirements.txt, only at install_requires.

Magda

Answer 4

I only ever use a setup.py and install_requires because there is only one place to look at. It is just as powerful as having a requirements file and there is no duplication to maintain.

Strut

The question is when to use one or the other, I didn't spell it out, but my answer is saying that I always use one and never the other. How is that not answering the question? – Strut