Python version support policy

[Helveg]

This is probably going to be a highly contentious issue, and it surprises me I didn't find (or missed) any open issues on it already:

What is the policy on supported Python versions?

New versions of software bring about new fancy features. Updating to these newer versions unlocks these fancy features. If you're in a situation where you can't, you'll have to stick with the released versions without these fancy new features.

I don't think there's many models out there, that have been developed ages ago in Python 2 that are dying, just absolutely dying for all of the new bleeding edge features of NEURON 8.0; or more surprisingly that they'd be willing to upgrade to NEURON 8.0 but not to Python 3 ;).

This decision to support older versions has a drastical impact on what is possible to achieve in the Python interface of NEURON, and although nothing much of the core functionalities of NEURON is written in Python, creating an up-to-date modern interface in Python for NEURON (#1081) will depend highly on which antiquated (and officially completely abandoned) versions of Python we have to take into account.

The Python Developer Survey 2020 shows 3% use of Python 3.5 or earlier and a rapidly dropping 5% use of Python 2 even before its official sunsetting in January 2020.

To me personally it is an important matter in which I have high stakes and the question boils down to this: How many years of a handicap on all the shiny new features of Python are you going to give me? ;) Who knows what Python 3.10 or 3.11 might bring, but I might be too old to ever use them by the time NEURON drops 3.9 😏

[Helveg]

Py2 needs to go. For minor versions and (oh dear god please no, not python4) upcoming major versions we need a policy.

[ramcdougal]

For practical purposes, this would mean that almost all Python-based NEURON models available on ModelDB before, say, 2018 or so (and many after) would not run in whatever version of NEURON makes that switch.

Making it so that NEURON can't run most examples of NEURON code would be problematic. (Admittedly, that's a bit dramatic of a way of putting it.)

Note that users are free to use all the shiny features of the latest Python. I use f-strings all the time, for example. The only people who have to build more robust code the works on older versions are the developers, which is exactly where the burden belongs.

[Helveg]

For practical purposes, this would mean that almost all Python-based NEURON models available on ModelDB before, say, 2018 or so (and many after) would not run in whatever version of NEURON makes that switch.

They would still run on the version of NEURON that they were made with. All it would take is ModelDB to add a field to the metadata that specifies NEURON version constraints. And we have a pip installable variant of NEURON available, 7.8.2 that will still work with all ModelDB models, a very very very reasonable "lower limit" NEURON version for ModelDB models.

Note that users are free to use all the shiny features of the latest Python. I use f-strings all the time, for example. The only people who have to build more robust code the works on older versions are the developers, which is exactly where the burden belongs.

Yes, I hope I didn't make it seem like this burden was on the users

[ramcdougal]

Python 2.7 support is a little messier than python.org dropping support. The distributions also have to drop support or otherwise people will keep using it. e.g. RHEL 8 promises to support python 2.7 until June 2024: https://access.redhat.com/support/policy/updates/rhel8-app-streams-life-cycle

[Helveg]

Python 2.7 support is a little messier than python.org dropping support. The distributions also have to drop support or otherwise people will keep using it.

Good point, but a user trying to use Python 2 and pip install NEURON will still get NEURON 7.8.2, a user that tries pip install NEURON==8.0 would also get a very reasonable "no version found matching your constraints" error. Someone building with CMake will also get a familiar error that the Python version requirements aren't met.

[ramcdougal]

Unfortunately, that's not true. There is no pip2 installable version of NEURON.

[Helveg]

Ah, so they all belong to the CMake category? That's still a very clear and user friendly scenario: They CAN try to use Python 2 because it's available on their distro, they'll fail, they'll have Python 3 ubiquitously available to them and instead try to CMake with Python 3. If they're entrenched in Python 2 code, well A) they've had 10 years to fix that B) tools like 2to3 exist.

[ramcdougal]

What should happen is that all the code that is on ModelDB should be curated to run in both 2 and 3... which isn't that hard for an individual model, but it's a pain to do en masse.

[Helveg]

I agree, the models on ModelDB should be able to be downloaded and executed even if they only work on Python 2, so py2 wheels as proposed in #1099 can ensure that and help in phasing out Python 2 support.

There is still the matter of how to deal in the future with the support of minor/major versions of one of the main dependencies of this project, if not managed properly this is a situation bound to repeat itself.

[alexsavulescu]

I guess the "unwritten" policy so far has been driven by adopting new Python versions over time, given the multitude of platforms and users. It's definitely not obvious to handle that.

The policy we should aim for is for supporting/dropping python versions based on several aspects:

• python x.y end-of-life (EOL)
• manylinux EOL
• platforms' EOL

And by the way, the fewer supported versions, the faster the CI 👌

[alexsavulescu]

We should encompass discussions following #1649 and #1570