Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to end support for Python 2.7 #2

Open
smmaurer opened this issue Jul 15, 2020 · 0 comments
Open

How to end support for Python 2.7 #2

smmaurer opened this issue Jul 15, 2020 · 0 comments

Comments

@smmaurer
Copy link
Member

smmaurer commented Jul 15, 2020

OSMnet v0.1.6 is the first UDST package to end support for Python 2.7. Here's what we figured out about how to do it smoothly.

Make version support explicit in the metadata

Pip and Conda will assume that a non-compiled package is compatible with all versions of Python unless you specify otherwise. It's important to mark this when dropping support for Python 2.7.

If it isn't marked, Pip in py27 will begin installing the package, then run into problems with dependencies, and exit with an error. But if you mark it, Pip will search for an older version of the package and install that one instead.

For Pip

Pip reads requirements from setup.py. Add a python_requires parameter like this. (Live example here.)

python_requires = '>=3.5',
install_requires = ...

For Conda

Conda reads requirements from meta.yaml in the conda-forge feedstock. Add a version to the Python run requirement like this. (Live example here.)

run:
  - python >=3.5

Stop building universal wheels

Universal wheels imply support for both Python 2 and Python 3. You build them with

python setup.py sdist bdist_wheel --universal

And the filenames look like osmnet-0.1.6-py2.py3-none-any.whl.

To make it clear that the package no longer supports Python 2, you need a non-universal pure Python wheel. You build it with

python setup.py sdist bdist_wheel

And the filename looks like osmnet-0.1.6-py3-none-any.whl. (If your active environment is Python 3, it creates a wheel for Python 3.)

Note that the wheels are the bdist_wheel part of the command -- the sdist part creates a tarball like osmnet-0.1.6.tar.gz, and we upload both to PyPI. Conda Forge uses the tarball for the conda release, and probably in some cases users install from it too.

Here's some more info: https://packaging.python.org/guides/distributing-packages-using-setuptools/#wheels

Choosing what version to require

Typically, we're dropping support for Python 2.7 either (a) because a dependency has done so, or (b) to use features from Python 3 or from a specific newer release.

In the case of OSMnet, some of the functionality was rewritten to require GeoPandas v0.7, which in turn requires Python 3.5 or higher. An easy way to see the requirements of dependencies is to look for the meta.yaml file in their conda-forge feedstock. (GeoPandas is here.)

Ending 32-bit Windows support

Dependencies that no longer support Python 2.7 often don't support 32-bit Windows environments either. For example, Pandas dropped this in v0.23.

Our AppVeyor tests are often running in win32, so this can cause them to fail. The fix is to update appveyor.yml to use a 64-bit copy of Python, like this. (Live example here, full list of options here.)

install:
  - "set PATH=C:\\Miniconda36-x64;C:\\Miniconda36-x64\\Scripts;%PATH%"

Very few people still use 32-bit Windows, but it's worth noting in the documentation and change log that support has been dropped.

@smmaurer smmaurer changed the title How to drop support for Python 2.7 How to end support for Python 2.7 Jul 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant