MAINT: Update supported Python versions

[asoplata]

Currently, we allow installation in all Python versions 3.8 and up, but there are several changes that need to be made:

• NEURON currently does not support the newly-released stable version Python 3.13 (see Python 3.13 support neuronsimulator/nrn#2640 ). They probably will soon, but until that happens, we should not allow installation with 3.13.
• We only test against 3.8, 3.11, and 3.12, but not 3.9 nor 3.10. I have done local tests against 3.9 and 3.10 on Windows, Mac, and Linux, and I can't find any reason not to include those versions in our tests.
• We should add "classifiers" for all the versions we support into our setup.py (example: NeuralEnsemble/neurotune@e8dadb5 )

edit: a word

[jasmainak]

I have done local tests against 3.9 and 3.10 on Windows, Mac, and Linux, and I can't find any reason to include those versions in our tests.

save the environment :) running these tests takes computation, if the gain is incremental, it's probably not worth it.

[asoplata]

whoops sorry Mainak I accidentally edited your comment instead of my own. I think I reverted it. (didn't know I could edit others comments!)

[asoplata]

me considering this and all its ramifications

You raise an excellent point. To me, this begs the question: in addition to not expanding our CI runs, why not also go further and decrease the CI runs we run by default? Now that we have a full-time developer, I think an effective setup could be the following:

• For all new PRs and their new commits, we run:

  • The current CI runners for MacOS, Linux, and Windows, but only for one major version, such as 3.12, which I believe is the current default version used by Anaconda (which we recommend using).

• Separately, we make a new Github Action to run our CI runners for master across all supported Python versions, but only once or twice a month. The vast, vast majority of our bugs are not version incompatibilities, but if any do arise, then I can use these tests (or my own local cross-version tests) to catch them.

• Another idea, depending on difficulty, would be to split the Sphinx doc generation runner into 2 parts:

  1. First part is the actual API documentation, autogenerated from docstrings etc., and whose runner could continue to run for every PR
  2. Second part would be the CPU-expensive Examples and Tutorials documentation generation. Similarly to above, this could be run infrequently, such as part of the once or twice a month CI. I don't think these necessarily need to be re-done for every PR, although I have yet to dive into understanding CircleCI's caching. If we don't already, we should have some tests which mock what is required for all the function calls in the Examples and Tutorials of the documentation.

[jasmainak]

would be to split the Sphinx doc generation runner into 2 parts:

see make html and make html-noplot. They essentially do this. I think mne-python has some CI magic to detect which files have been touched and only re-build those. Essentially after each CI build, you would save the build to a cache. Then, before the build the cache would be restored. If sphinx-gallery is asked to re-build in this directory, it will only re-build files that have actually changed.

[jasmainak]

The current CI runners for MacOS, Linux, and Windows, but only for one major version, such as 3.12, which I believe is the current default version used by Anaconda (which we recommend using).

I think it's fair to do an "L" shaped CI-run rather than a matrix ... one version, all OS and one OS (Linux), all versions. Keep it simple stupid as far as possible and try not to get too creative :) The more custom your solution is, the harder it will be maintain in the future.

[asoplata]

would be to split the Sphinx doc generation runner into 2 parts:

see make html and make html-noplot. They essentially do this. I think mne-python has some CI magic to detect which files have been touched and only re-build those. Essentially after each CI build, you would save the build to a cache. Then, before the build the cache would be restored. If sphinx-gallery is asked to re-build in this directory, it will only re-build files that have actually changed.

Yes, there's a lot I still have to learn about our use of Sphinx build system. As far as I can tell make html-noplot has been broken for several months, so I need to repair it and install some deps before comparing to make html, etc. I also need to dig into enabling parallelization for its components, etc. I will probably dig in when we are revamping all the HNN websites as a whole over the next couple months.

[asoplata]

Adding a note about this: we may want to drop "official" support for 3.8, including for testing, since it is officially no longer supported (see https://devguide.python.org/versions/ ). From personal recollection, I feel like I have noticed macos-3.8 failing the test a bit more frequently than other versions, though I have no data to back this up.

That said, if someone reaches out to us and specifically requests 3.8 support, we can totally do that, either entirely or (if there are growing incompatibilities) in a special branch.

[jasmainak]

It's too complicated to support a special version in a separate branch :) I would recommend just dropping support when we are ready ... I am one of those guilty users still using 3.8, should switch to latest version!

[asoplata]

I meant a special branch only in the worst-case-scenario: someone explicitly needs the old version and cannot upgrade, but there are fundamental issues preventing us supporting 3.8 in the master branch, such as our voila dependency becoming incompatible with the version, etc. etc.

[jasmainak]

Virtual environments exist for someone wanting to use older version. But it would be hard to provide continued support due to the very reasons you mention + small dev team