search

tulip-control / polytope

Geometric operations on polytopes of any dimension
https://pypi.org/project/polytope
Other
73 stars 19 forks source link

remove support for Python 2.7, 3.5, 3.6 #70

Closed johnyf closed 3 years ago

johnyf commented 3 years ago

Python 2.7 development has completely stopped. The Python ecosystem has now moved to Python 3. Most major packages have ceased support for Python 2.7, for example numpy did so about 2 years ago (numpy == 1.17.0). So it is time to remove support for Python 2.7 from polytope. It suffices to remove 2.7 from the supported Python versions, pass the parameter python_requires to the function setuptools.setup, and use features available on Python 3, and in newer versions of dependencies where needed.

This change is motivated by the benefits of using the function numpy.random.default_rng that is available in newer versions of numpy. There is no reason to constrain polytope's code to remain compatible with Python 2.7, and thus not use new functionality available in recent versions of dependencies.

johnyf commented 3 years ago

As of commit 9ee3f9634089c61353dfa4aec2d3d9b4cfb6905f, support for Python 2.7 has been removed, and also support for Python 3.5 and 3.6 has been removed. For motivation, please read the commit messages on branch dev.

slivingston commented 3 years ago

I strongly support this. I think that it can be done without much more discussion. Actually the same for Tulip. I am now a "member of industry" and I can confirm that Python 2.7 is not for new development and mostly survives only where it is deeply embedded in a product, etc.

As for versions of Python 3, I agree with following NumPy. If users have difficulties because of requirements of 3.6, we can discuss or patch as needed. To be explicit, 3.5 is past end-of-life, but 3.6 is scheduled to continue to receive security updates until end of this year.

slivingston commented 3 years ago

Is there any reason not to make the same changes in https://github.com/tulip-control/tulip-control/ ?

murrayrm commented 3 years ago

I think it would be fine to move to 3.7+ for tulip-control.

johnyf commented 3 years ago

Thank you for the comments, I merged the changes from branch dev to the mainline branch of polytope (a23ddcfd0deb42f6caf2c34bfec23ad39e89289a), so now the supported Python versions have been updated.

I do not know of any reason why to not make the same changes to tulip.

A relevant change is to pass the parameter python_requires to the function setup.setuptools in order to ensure that newer versions of tulip will not be unknowingly installed on unsupported Python versions (this check can be explicitly deactivated with pip install --ignore-requires-python).

This defines the metadata field Requires-Python that is specified in PEP 345. It appears that PEP 503 specifies that when this field is present and communicated by PyPI, then installer tools like pip should ignore the download when running on a Python version that is unsupported by the package.

For python_requires to work effectively, the users need to have pip >= 9.0.0 and setuptools >= 24.3.0 (setuptools >= 24.2.1 seems sufficient too). In any case, python_requires is one of the most dependable approaches for ensuring this.

Including Requires-Python metadata will result in "Requires: Python >=3.7" being displayed in the package's page on PyPI, in addition to the Trove classifiers that declare supported Python versions.

Relevant resources:

The documentation at: https://packaging.python.org/guides/distributing-packages-using-setuptools/#classifiers reads:

Although the list of classifiers is often used to declare what Python versions a project supports, this information is only used for searching & browsing projects on PyPI, not for installing projects. To actually restrict what Python versions a project can be installed on, use the python_requires argument.

Also, I removed the Python 2 Trove classifiers, but did not add the classifier "Programming Language :: Python :: 3 :: Only", because I am not sure what the convention is, because Requires-Python will have the intended effect independently of what Trove classifiers are used, and also because polytope remains almost compatible with Python 2.7 (the only reason why parts of polytope would now not work on Python 2.7 is numpy version).

Regarding Python 3.10 support, I created a branch py310 that replaces nose with pytest (except inside the script run_tests.py, which needs more studying), adds Python 3.10-dev to the CI test environments ("DRAFT" commit), and declares support for Python 3.10 in the Trove classifiers. The environment setup for Python 3.10 failed on that branch because Python 3.10 has not yet been released, so there does not exist a numpy version on PyPI for Python 3.10.

johnyf commented 3 years ago

I have now changed tulip to require Python >= 3.7. For reasons orthogonal to this Python version requirement, updates were needed to the CI testing configuration. These are mostly completed, and described at: https://github.com/tulip-control/tulip-control/issues/246.

So this issue appears to have been addressed.

Regarding CI testing with Python 3.10 (mentioned above: https://github.com/tulip-control/polytope/issues/70#issuecomment-851610661), this can be revisited after Python 3.10 has been released and wheels for numpy and scipy for Python 3.10 become available on PyPI. (The CI error was because only binaries are downloaded for numpy and scipy using pip (to avoid CI timeouts and speedup the test runs):

https://github.com/tulip-control/polytope/blob/a23ddcfd0deb42f6caf2c34bfec23ad39e89289a/.travis.yml#L22

so pip cannot find such wheels for Python 3.10. I tried building them locally, and on Python 3.10 building scipy from source distributions available from PyPI did not succeed.)

johnyf commented 3 years ago

This issue has been addressed as of commit beadd1263adda6093c8ced3db1afd1a6ceeb069c.

About the branch py310 (https://github.com/tulip-control/polytope/issues/70#issuecomment-853710592), which adds Trove classifiers and CI testing for Python 3.10, I tried locally to override the Python version used by pip when searching for wheel files to download:

pip install -U --only-binary=":all:" --python-version="3.9" --target=/tmp/foo numpy scipy

(The arguments --only-binary=":all:" and --target were required by pip; otherwise pip exited with a message that certain additional arguments need to be given.)

Installation did complete without errors in Python 3.10, but when I cd /tmp/foo and try python -c "import numpy", I get an error that starts with:

> python -c "import numpy"
Traceback (most recent call last):
  File "/.../foo/numpy/core/__init__.py", line 22, in <module>
    from . import multiarray
  File "/.../foo/numpy/core/multiarray.py", line 12, in <module>
    from . import overrides
  File "/.../foo/numpy/core/overrides.py", line 7, in <module>
    from numpy.core._multiarray_umath import (
ModuleNotFoundError: No module named 'numpy.core._multiarray_umath'

The module that was not found is an extension module, namely numpy/core/_multiarray_umath.cpython-39-darwin.so. I opened #71 for tracking support for Python 3.10 (mainly CI testing on Python 3.10).