Closed spoeschel closed 6 months ago
Should we also be specifying the Python version as part of this? e.g. https://pip.pypa.io/en/stable/reference/pip_install/#requirement-specifiers says that in the requirements.txt
file used by pip you can specify something like SomeProject ==5.4 ; python_version < '2.7'
where for us SomeProject
is this project.
As far as I understand the related PEP 508, this specifier means that the requirement (an explicitely specified version or otherwise the latest version of it) is only installed if the mentioned Python version matches the filter condition. It does not mean that a version of the requirement is selected/installed, that supports the specified Python version (which would be great).
So the specifier would only allow to not install the LIT itself in case e.g. Python 3 was used....but I think that the version hint in the README is sufficient here. We could just change the "2.7+" to "2.7" to indicate that Python 3 is not supported by this branch.
Yeah, I guess you're right. Maybe the best option is a Makefile step that checks the python version number is within acceptable bounds. Cheeky stackoverflow search reveals https://stackoverflow.com/questions/4933285/how-to-detemine-python-version-in-makefile with a few ways to do it.
Using the Makefile seems to be the best way to abort using the wrong Python version as early as possible. The sys.version_info
approach seems to be more elegant than parsing python --version
. Maybe it makes also sense to do the actual version number comparison in Python itself then.
I think the work needed to close this issue was done. It may be nice to check the python version, but in Python 3 with e.g. poetry, there are known ways to do this, so I don't think it's helpful to hold this issue open waiting for some fix that's never coming, for Python 2.7. Closing as done, with thanks again to @spoeschel .
As a more generic and future-proof fix for issues like #533, add all currently used package versions to
requirements.txt
usingpip freeze
.