Structuring setup.py and requirements.txt so that pip installs properly

Question

I'm trying to write a python package that can be installed from PyPI and am having trouble getting my head around how exactly to structure setup.py and requirements.txt properly.

I know that they have different semantics and different purposes with setup.py defining whats needed, and requirements.txt given exact versions. I also know that you shouldn't read requirements.txt into setup.py.

So what I need to know is how to structure setup.py and requirements.txt so that when my package is installed from PyPI the reight requirements are installed.

In my example, I need django-haystack (the latest version is 2.5.1), but my code is only compatible with django-haystack version 2.5.0, so my setup.py and requirements.txt are as shown below:

setup.py:

setup(
    name='my_package',
    install_requires = [
        'django-haystack',
    ],
)

requirements.txt:

django-haystack==2.5.0

How can I structure my setup code so that when this is installed, django-haystack==2.5.0 is installed not the latest?

score 2 · Answer 1 · answered Oct 31 '16 at 23:58

First, a warning: specify explicit version requirements in a setup.py file without a range will guarantee frustration for end-users in the future.

You can simply do it like so in the setup.py file.

setup(
    name='my_package',
    install_requires=[
        'django-haystack==2.5.0',
    ],
)

However, if another user wish to use another package that requires django-haystack latest version, they won't be able to install your package as defined due to version conflict issues. Of course, if the package at hand is so flaky that it can't even attempt to use semantic versioning then there isn't really much can be done.

Now if all you are after is a reproducible build, the requirements.txt method can be used for explicit version requirements for all packages within your environment, which is out of band from the typical package dependency structure, however it won't suffer from the potentially crippling lockdown from conflicting requirements that aren't actually in conflict. zc.buildout is an alternative, but much more heavier but it does a lot more than just Python.

Part of the reason for version pinning is I'm trying to use pyup.io to help both test my dependencies and keep them up to date. — , Nov 01 '16 at 00:04
I recently learned about pyup.io and am wondering what is its use case? Shouldn't my tests tell me where things break when I update my virtualenv? I guess using step by step updates would make it more clear for big projects? — K.-Michael Aye, Nov 08 '16 at 07:12

Structuring setup.py and requirements.txt so that pip installs properly

1 Answers1