Should we gitignore the .python-version file?
Question:
I have a .python-version file, and when I create a Python repo with github and specify that it should have a .gitignore, it adds the .python-version file to it. It seems to me that that file should NOT be ignored since other people running the code on different machines would want to know what version of Python they need.
So why is it .gitignored?
Answers:
The reason why .python-version should be gitignored is because its version is too specific. Tiny versions of Python (e.g. 2.7.1 vs 2.7.2) are generally compatible with each other, so you don’t want to lock down to a specific tiny version. Furthermore, many Python apps or libraries should work with a range of Python versions, not just a specific one. Using .python-version indicates that you want other developers to use an exact, specific Python version, which is usually not a good idea.
If you want to indicate the minimum Python version needed, or otherwise a version range, then I believe documenting that in a README is a more appropriate solution.
While being too specific, you can still version that file (meaning: not include it in the default .gitignore), as :
- it will be used only by
pyenv
- it is a good addition to the
README, in order to illustrate what version of python is recommended for the specific project,
- it can be overridden easily (if you are using
pyenv), or simply ignored (if you don’t have pyenv).
As the article “How to manage multiple Python versions and virtual environments ” states:
When setting up a new project that is to use Python 3.6.4 then pyenv local 3.6.4 would be ran in its root directory.
This would both set the version, and create a .python-version file, so that other contributors’ machines would pick it up.
But:
pyenv looks in four places to decide which version of Python to use, in priority order:
- The
PYENV_VERSION environment variable (if specified).
You can use the pyenv shell command to set this environment variable in your current shell session.
- The application-specific
.python-version file in the current directory (if present).
You can modify the current directory’s .python-version file with the pyenv local command.
- The first
.python-version file found (if any) by searching each parent directory, until reaching the root of your filesystem.
- The global version file. You can modify this file using the
pyenv global command.
If the global version file is not present, pyenv assumes you want to use the “system” Python. (In other words, whatever version would run if pyenv weren’t in your PATH.)
Well sir I think answer to your question is YES. I just openend GitHub official repo and checked the project gitignore.
It showed .python-version file mentioned there.
And if it’s not getting ignored you can simply check for correct way to mention.
It can also be a bit problematic when using python virtual environments, as people may want to use virtual environment names different than 3.7.2/envs/myvenv.
Old post but still relevant.
My answer would be "it depends".
The name of a virtual env can also be used in .python-version, if it is managed with the help of the virtualenv plugin of pyenv. This makes this file pretty useless it the project is managed on a public Git repo and you can exclude it (but not to do is harmless as told in other answers).
But (and I am in this situation) if you manage the project on a private repo and share virtual envs, it can make sense to not exclude it from Git. This allows you to work with a different environment (including the Python version) on an experimental branch of the project. Of course, it would have been far cleaner to fork or clone the original project and experiment with the new env in the copy, but sometimes it easier to just create a new branch.
At the end of the day, IMHO there is no universal answer to the question, and it depends on your workflow.
I have a .python-version file, and when I create a Python repo with github and specify that it should have a .gitignore, it adds the .python-version file to it. It seems to me that that file should NOT be ignored since other people running the code on different machines would want to know what version of Python they need.
So why is it .gitignored?
The reason why .python-version should be gitignored is because its version is too specific. Tiny versions of Python (e.g. 2.7.1 vs 2.7.2) are generally compatible with each other, so you don’t want to lock down to a specific tiny version. Furthermore, many Python apps or libraries should work with a range of Python versions, not just a specific one. Using .python-version indicates that you want other developers to use an exact, specific Python version, which is usually not a good idea.
If you want to indicate the minimum Python version needed, or otherwise a version range, then I believe documenting that in a README is a more appropriate solution.
While being too specific, you can still version that file (meaning: not include it in the default .gitignore), as :
- it will be used only by
pyenv - it is a good addition to the
README, in order to illustrate what version of python is recommended for the specific project, - it can be overridden easily (if you are using
pyenv), or simply ignored (if you don’t havepyenv).
As the article “How to manage multiple Python versions and virtual environments ” states:
When setting up a new project that is to use Python 3.6.4 then
pyenv local 3.6.4would be ran in its root directory.
This would both set the version, and create a.python-versionfile, so that other contributors’ machines would pick it up.
But:
pyenvlooks in four places to decide which version of Python to use, in priority order:
- The
PYENV_VERSIONenvironment variable (if specified).
You can use thepyenv shellcommand to set this environment variable in your current shell session.- The application-specific
.python-versionfile in the current directory (if present).
You can modify the current directory’s.python-versionfile with thepyenv localcommand.- The first
.python-versionfile found (if any) by searching each parent directory, until reaching the root of your filesystem.- The global version file. You can modify this file using the
pyenv globalcommand.
If the global version file is not present,pyenvassumes you want to use the “system” Python. (In other words, whatever version would run ifpyenvweren’t in yourPATH.)
Well sir I think answer to your question is YES. I just openend GitHub official repo and checked the project gitignore.
It showed .python-version file mentioned there.
And if it’s not getting ignored you can simply check for correct way to mention.
It can also be a bit problematic when using python virtual environments, as people may want to use virtual environment names different than 3.7.2/envs/myvenv.
Old post but still relevant.
My answer would be "it depends".
The name of a virtual env can also be used in .python-version, if it is managed with the help of the virtualenv plugin of pyenv. This makes this file pretty useless it the project is managed on a public Git repo and you can exclude it (but not to do is harmless as told in other answers).
But (and I am in this situation) if you manage the project on a private repo and share virtual envs, it can make sense to not exclude it from Git. This allows you to work with a different environment (including the Python version) on an experimental branch of the project. Of course, it would have been far cleaner to fork or clone the original project and experiment with the new env in the copy, but sometimes it easier to just create a new branch.
At the end of the day, IMHO there is no universal answer to the question, and it depends on your workflow.