Drop Python 3.8, depend on scipy>=1.6.0

[mwtoews]

Python 3.8 reached it's end-of-life in 2024-10-07 (PEP 569), so should be dropped.

Change SciPy dependency to >=1.6.0 to overlap with Python 3.9. Similar with NumPyDoc. All other deps have not changed, as they appear to overlap with Python 3.9.

gstools-core only supports Python>=3.10, so add conditional so that (e.g.) uv sync --all-extras succeeds.

[MuellerSeb]

Thanks for your contribution. I understand the dropping of support for python versions and dependencies in case of fundamental libraries, but in case of GSTools, if we don't use new features, why drop support for a python version or why increase the dependency version of scipy for example? In the past we only increased the version if we require a feature that was added in a later version.

Maybe this is a good point to ask: What do we gain from being more restrictive?

Python 3.8 reached it's end-of-life in 2024-10-07 (PEP 569), so should be dropped.

Sounds like this is the standard procedure, but where is that written?

[MuellerSeb]

https://packaging.python.org/en/latest/guides/dropping-older-python-versions/#dropping-a-python-version

In principle, at least metadata support for Python versions should be kept as long as possible, because once that has been dropped, people still depending on a version will be forced to downgrade.

I totally agree with this statement by the Python Packaging User Guide.

And for example: Python 3.8 is the default version of Ubuntu 20.04 LTS.

[mwtoews]

Extending support 3.8 is fine in principle, but the current setup is broken for tools like uv sync, which raises errors when dependencies are not met, e.g. I see:

$ uv sync
  × No solution found when resolving dependencies for split
  │ (python_full_version == '3.8.*'):
  ╰─▶ Because the requested Python version (>=3.8) does not satisfy
      Python>=3.9 and all versions of stonefish-license-manager
      depend on Python>=3.9, we can conclude that all versions of
      stonefish-license-manager cannot be used.
      And because meshzoo==0.11.6 depends on stonefish-license-manager and
      only meshzoo==0.11.6 is available, we can conclude that meshzoo==0.11.6
      cannot be used.
      And because gstools[doc] depends on meshzoo==0.11.6 and your project
      requires gstools[doc], we can conclude that your project's requirements
      are unsatisfiable.

      hint: The `requires-python` value (>=3.8) includes Python versions
      that are not supported by your dependencies (e.g., all versions of
      stonefish-license-manager only supports >=3.9). Consider using a more
      restrictive `requires-python` value (like >=3.9).

In this case, a minimal patch to resolve the dependency issue is:

diff --git a/pyproject.toml b/pyproject.toml
index 3e09aaf..df2497b 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -58,7 +58,7 @@ dependencies = [
 doc = [
     "myst_parser",
     "matplotlib>=3.7",
-    "meshzoo>=0.7",
+    "meshzoo>=0.7; python_version >= '3.9'",
     "numpydoc>=1.1",
     "pykrige>=1.5,<2",
     "pyvista>=0.40",
@@ -71,7 +71,7 @@ plotting = [
     "matplotlib>=3.7",
     "pyvista>=0.40",
 ]
-rust = ["gstools_core>=1.0.0"]
+rust = ["gstools_core>=1.0.0; python_version >= '3.10'"]
 test = ["pytest-cov>=3"]
 lint = [
     "black>=24",

(In this case it looks like meshzoo has only one release in PyPi, which depends on other projects that require Python 3.9).

The SciPy dep was only incremented to overlap Python 3.9 support, since SciPy 1.5.4 only supported up to Python 3.8. The current scipy>=1.1.0 is not realistic, since 1.1.0 supported much older Python versions.

But as to the broader question of dropping Python beyond it's intended EOL, there is a spectrum of opinions. Some say to relax it to as many versions as possible, because the code still functions the same. But this requires more testing and more developer time to maintain in a complex dependency ecosystem (e.g. meshzoo). And the other side of the spectrum is SPEC 0 that suggests supporting the previous ~3 releases (currently Python 3.11-3.13), as adopted by NumPy. This is is usually the approach for projects that compile many variations of binary wheels, to conserve computer time and disk space.

So if you're certain folks out there are actually using Python 3.8, then there is no issue in keeping it in support, as this is a pure Python project with a single wheel. I can re-adjust this PR to suite, let me know.

[MuellerSeb]

• Regarding gstools-core: @LSchueler I thought this is compatible with versions 3.8+ (since we use abi3 wheels there) why did we drop 3.8 and 3.9 there?
• regarding meshzoo: I am certain that there were more versions in the past but @nschloe started removing packages and making them closed source. I think we should remove this dependency on meshzoo in the future (just create the simple example mesh by hand)
• since gstools-cython now is separated, we don't re-compile all the time, so keeping python 3.8 here is ok for now. For Cython it is also true that the new version 3.1 supports python 3.8+.

[LSchueler]

Thanks for raising this issue!
I don't really see a problem in dropping py3.8 support for the optional dependency. I guess not many people with py3.8, if any, will be compiling the docs? But yeah I agree that the meshzoo dependency has become the fundamental problem here.

I'm going to check the dependencies of gstools-core next week. And I hope to also find some time to drop the meshzoo dependency.

[LSchueler]

Hi again,

I just updated gstools-core to v1.1.0 and now included Py3.8 as the minimum supported version. It works like a charm. I'll soon work on the meshzoo dependency.