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.
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.)
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 apython_requiresparameter like this. (Live example here.)For Conda
Conda reads requirements from
meta.yamlin the conda-forge feedstock. Add a version to the Python run requirement like this. (Live example here.)Stop building universal wheels
Universal wheels imply support for both Python 2 and Python 3. You build them with
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
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_wheelpart of the command -- thesdistpart creates a tarball likeosmnet-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.yamlfile 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.ymlto use a 64-bit copy of Python, like this. (Live example here, full list of options here.)Very few people still use 32-bit Windows, but it's worth noting in the documentation and change log that support has been dropped.