33

I'm using virtualenv to develop a django application with a team. The server we're deploying on is running python 2.6, but the default for our machines is 2.7.3. Is there any way to specify python version in the requirements.txt file, or something similar, within the code base?

I know requirements.txt is a pip thing, and python version is a virtualenv thing, but it would be really convenient not to have to tell every new person joining the team how to set up their virtualenv.

Arion
  • 1,792
  • 2
  • 18
  • 29
  • 2
    I'm not understanding what's motivating your question. Is your code written for `2.6` or `2.7`? If it's not written for `2.6` it's not going to work on your server obviously, so I don't know what you want to do :). Assuming it is written for `2.6`, just document that it's `2.6+`, and there's no need to particularly specify to use `2.6` when creating a venv, what's wrong if someone uses `2.7`?. – Julian Aug 09 '12 at 18:50
  • 2
    The code is written for 2.6 since the servers require it. It should be documented, but I'd like enforce 2.6 through virtualenv then just tell people it's 2.6+ and hope they read the python docs thoroughly. – Arion Aug 09 '12 at 21:21
  • 1
    This question has been answered here: http://stackoverflow.com/a/33451105/1959808 – 0 _ May 21 '16 at 23:45
  • 1
    Possible duplicate of [requirements.txt depending on python version](https://stackoverflow.com/questions/19559247/requirements-txt-depending-on-python-version) – Morgoth Aug 21 '17 at 18:10

6 Answers6

17

Neither pip nor virtualenv install python (though pip tries). They use whatever you specify.

You could write a README that mentions required Python version or provide a fabric script that can deploy to localhost and specify the version there. For example, instructions to install virtualenv, pip, distribute.

For those people who don't read instructions there could be a CI system (jenkins, buildbot) that can run unit-tests using supported python versions (before/after commit).

To manage multiple python installation you could use something like pythonz.

Community
  • 1
  • 1
jfs
  • 399,953
  • 195
  • 994
  • 1,670
6

You can't put that in requirements.txt, but you can add this code at the top of the script:

import sys
if sys.version_info[0:2] != (2, 6):
    raise Exception('Requires python 2.6')
wisbucky
  • 33,218
  • 10
  • 150
  • 101
3

it would be really convenient not to have to tell every new person joining the team how to set up their virtualenv

Just add it to the normal set of instructions you give new members when the join; right in the same place when you tell them about the internal documentation wiki, the password to the wifi and the phone number to the sandwich delivery shop.

It will be extremely uncovenient to not have to tell people and have them figure it out themselves; the first time they submit something that uses collections.Counter only to find out it broke the build because the server doesn't have 2.7.x

Burhan Khalid
  • 169,990
  • 18
  • 245
  • 284
  • 3
    That's the fallback plan, but I would prefer a programmatic solution to a programmatic problem. – Arion Aug 09 '12 at 21:15
  • I'm not sure this qualifies as a programmatic problem; this is simply documentation/on-boarding issue. If you *must*, you can add a check to your deployment script/hook that verifies the Python version; but then what's the point? Even if the version doesn't match - your code might still run. You would need to check if your code is using features that were introduced in 2.7, for which I don't know of an automated way. – Burhan Khalid Aug 09 '12 at 21:16
  • 2
    "I'm not sure this qualifies as a programmatic problem; this is simply documentation/on-boarding issue." By that logic you shouldn't have a requirements.txt at all because then people might assume it is the most recent version of a library and use features from that library that don't exist in the version they are actually using. Besides if you don't have unit tests (which would break in your example) then you are playing a risky game anyway. – semicolon May 03 '15 at 10:20
0

As per your comment, the only issue here should be making sure no 2.7-only code makes it into your code base. For that I recommend using tox, and having it configured to create a 2.6 environment to test on, so that when your coworkers run your test suite, the tests are run in a 2.6 virtual environment.

Julian
  • 3,375
  • 16
  • 27
0

You can also specify the default Python by this command:

sudo update-alternatives  --set python /usr/bin/python3.7
Farzad Amirjavid
  • 649
  • 5
  • 13
0

There is no way to generate the Python version automatically using pip. However, if you consider using conda to manage your Python environment and dependencies, you can create a file named environment.yml that includes all the dependencies and the Python version used in your project. To generate the environment.yml file, use the following command:

conda env export > environment.yml

This will create a environment.yml file in the current directory, containing a list of all installed packages and their specific versions, as well as the Python version used in your project.

To create a new environment from the environment.yml file, use the following command:

conda env create -f environment.yml

This will create a new conda environment with the same dependencies and Python version as the original environment.

Super Kai - Kazuya Ito
  • 22,221
  • 10
  • 124
  • 129