Can aenum be made optional?

[micahcochran]

Can aenum be made optional? It causes some complications for packagers https://lists.debian.org/debian-gis/2019/06/msg00000.html

Originally posted by @hobu in #302 (comment)

[micahcochran]

enumerations (enum) were introduced in Python versions 3.4. For Python versions below 3.4, aenum is required.

@snowman2 Is _missing_ the only feature of enums that requires Python 3.6+ implementation?

[jorisvandenbossche]

The _missing_ is certainly not essential, and the same behaviour can be mimicked with some extra code. So if it gives problems for packaging, I think it is an option to remove the dependency.

[snowman2]

@hobu, is enum34 an option for a dependency? If so, then we can definitely get around this with some extra code as mentioned by @jorisvandenbossche.

If not, another option (though not super great) would be to copy the needed code from aenum into pyproj so we fully support python 2.7-3.x without the aenum dependency.

[hobu]

@hobu, is enum34 an option for a dependency

Unclear. I was just reporting @sebastic's issue on the Debian side. Maybe he has some suggestions that will make things more convenient on the packaging side.

[sebastic]

Packaging Python modules is generally no problem, aenum is a bit special though as mentioned on the debian-gis list. The Python 2/3 tests are not handled well, which requires patching to do better. There are also test failures with Python 3.7 which I haven't investigated further.

Because pyproj only requires it for Python < 3.6 which we no longer have in Debian unstable, I didn't want to spend much time on the issue. After sleeping on it, I just included the module as a patch in the pyproj package to have the _missing_ support available for Python 2.7 for the short time we'll still support it in GIS packages, but mostly for UbuntuGIS which backports the Debian packages for Ubuntu LTS releases (of which xenial still uses Python 3.5, like Debian stretch). By the time we transition to PROJ 6 Python 2 support is most probably not very relevant any more, as it will be after its EOL.

It would be great if pyproj wouldn't require a non-standard module for older Python releases, but the workaround we have now will do too.

[snowman2]

I am glad to hear that you have a good workaround! Apologies for the trouble, I didn't realize that it would be such a pain to package aenum.

[snowman2]

I am thinking that since you currently have a workaround, we will wait to remove aenum until pyproj dropps support for Python 2 (#331). This way no changes will be needed on your end to add enum34.

[snowman2]

Addressed in #373. aenum will be removed in the 2.3.0 release.