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 seve
The Python Packaging User Guide has a page about this topic, I highly recommend you read it:
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
.
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
)
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.
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.