What is the best way to distribute a Python package that requires a minimal Python version

Question

I have a Python 2 project ('foo 0.1.7') that required Python 2.4 or later.

Now I ported it to Python 3 ('foo 0.2.0') in a way that it still is compatible with Python 2, but the requirements are now lifted to Python 2.6 or later.

• I know that there is a --target-version=2.6 option for setup.py, that can be used with upload, but that seems not to be meant as '2.6 or higher'
• The setup command has an install_requires option, but this is for required packages, .not Python interpreter.

I could do something like this in setup.py of 'foo 0.2.0':

if sys.hexversion < 0x02060000:
    raise RuntimeError('This package requires Python 2.6 or later, try foo 0.1.7')

but I would prefer if easy_install foo would resolve this in some way.

So, how should I deploy this on PyPI?

Answer 1

I know that there is a --target-version=2.6 option for setup.py, that can be used with upload, but that seems not to be meant as '2.6 or higher'

It is actually an option for bdist_wininst or bdist_msi, and indeed does not include “or higher”.

The setup command has an install_requires option, but this is for required packages, .not Python interpreter.

Maybe putting 'Python >= 2.6' in install_requires could work: Python 2.5 up to 3.2 create a Python-blahblah-pyXY.egg-info file, so if you’re lucky easy_install may find that the requirement is satisfied. If not it will probably try to download from PyPI, so uh...

I could do something like this in setup.py of 'foo 0.2.0': if sys.hexversion < 0x02060000: raise RuntimeError('This package requires Python 2.6 or later, try foo 0.1.7')

This is actually the current common idiom. In addition, using the “Programming Language :: Python :: X.Y” trove classifiers will give information for humans (I’m not aware of any tool using that info).

In the short-term future, there is hope. The specification for Python distributions metadata has been updated, and the latest version does contain a field to require a specific Python version: http://www.python.org/dev/peps/pep-0345/#requires-python

Regarding tool support: distutils is frozen and won’t support it, setuptools may or may not add support, its fork distribute will probably gain support, and distutils2/packaging already supports it. distutils2 includes a basic installer called pysetup, which should respect the Requires-Python field (if not, please report to bugs.python.org).

Now, to address your problem right now, you can do one of these things: - declare that your project only supports 2.6+ - document that 2.4 users need to pin the version when downloading (e.g. pip install "foo==0.1.7")

Answer 2

What it sounds like you're looking for is a way to upload both version 0.1.7 and 0.2.0 of your program, and have easy_install-2.5 automatically use 0.1.7, while easy_install-2.6 would use 0.2.0.

If that's the case, I'm not sure if it's possible to do with the current system... the raise RuntimeError() check might be the best option currently available; people who install your project would then have to manually easy_install-2.5 -U "proj<0.2", or something similar.

That said, there's a dedicated group currently working to replace distutils, setuptools, etc with an updated library named packaging. This new library combines the features of the existing distutils enhancement libraries, as well as a host of other improvements. It's slated for inclusion in Python 3.3, and then to be backported as distutils2.

Of special relevance to your question, it contains many enhancements to the setup metadata; including a "requires_python" option, which seems tailor made to indicate exactly the information you want. However, I'm not sure how they plan to make use of this information, and if it will cause the new setup system to behave like you wanted.

I'd recommended posting to the fellowship of the packaging, the google group dedicated to the development of the new system, they would be able to give details about how requires_python is supposed to work... and possibly get the installation behavior you want in on the ground floor of the new system if it seems feasable (and isn't already there).