Repository: spack/spack

Issue:
Revert "Update various Jupyter packages"
Reverts spack/spack#36332

This is breaking our rhel8 test environment in CI.


Discussion:
Can we stop supporting installs for Python 3.6? Also, I don't think we need to revert this PR entirely, we just need to specify which versions require Python 3.7+ in CI (and add comments so I don't remove this in the future). I'm not supporting 3.6, and the tests don't catch this, so there's not much I can do here. 
Can we either merge this or get a version that reverts the Python 3.6 changes?

I think it was a mistake to not support Python 3.6, or at least to proactively remove the version constraints for it.  Per our survey results from a week ago, there are still 31% of users running Spack on 3.6:

<img width="786" alt="Screenshot 2023-03-23 at 1 12 26 PM" src="https://user-images.githubusercontent.com/299842/227341187-b1086af6-7ebc-4ead-bdbc-629c663006e0.png">

> Can we stop supporting installs for Python 3.6?

I think based on the chart above, no.  It's breaking us in environments that we will continue to care about for a long time.  Or rather one very specific environment that is still supported and that many users still care about.  Note the usage of Alma, Centos, Rocky, and RHEL here.

<img width="782" alt="Screenshot 2023-03-23 at 1 14 11 PM" src="https://user-images.githubusercontent.com/299842/227341669-3e0f8d93-03a5-4dcf-a3db-c376c632f313.png">

> I'm not supporting 3.6, and the tests don't catch this, so there's not much I can do here.

I've asked @alalazo to put a CI job in for the environment.  I don't think you have to actively support 3.6; just don't actively remove the bounds for it.  In this PR I don't think it would be a horrible additional burden to not do those deletions, would it?
This isn't about "running on", this is about "installing". We can still run Spack with Python 3.6, but I don't think it's worthwhile to support bootstrapping dependencies or installing packages. Python 3.7 reaches EOL in June and I'm planning on deprecating it and removing it after the next release. This problem will only get worse if we continue to support bootstrapping with 3.6 and don't properly test it in CI until after it's been merged.

Feel free to submit a PR that re-adds constraints for 3.6, or stop testing bootstrapping on 3.6, but I just want to make it clear that I'm not going to be supporting EOL Python so someone else will have to do that.
> In this PR I don't think it would be a horrible additional burden to not do those deletions, would it?

I'm only deleting lines that are no longer relevant for Python versions I support. This includes 3.7. I can stop doing this, although I've already done it for hundreds of packages, but I would someday like to be able to clean up these packages and remove version constraints that are no longer relevant.
As long as CI catches issues during the PR process instead of after, I'm fine with leaving in irrelevant constraints where they are still needed. But please don't revert my PR unless you plan on submitting a modified version of the PR that passes the tests, it took a long time to update those packages.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/py-typing-extensions/package.py b/var/spack/repos/builtin/packages/py-typing-extensions/package.py
--- a/var/spack/repos/builtin/packages/py-typing-extensions/package.py
+++ b/var/spack/repos/builtin/packages/py-typing-extensions/package.py
@@ -26,5 +26,8 @@ class PyTypingExtensions(PythonPackage):
     version("3.7.2", sha256="fb2cd053238d33a8ec939190f30cfd736c00653a85a2919415cecf7dc3d9da71")
     version("3.6.6", sha256="51e7b7f3dcabf9ad22eed61490f3b8d23d9922af400fe6656cb08e66656b701f")
 
+    # typing-extensions 4+ uses flit
+    depends_on("python@3.7:", when="@4.2:", type=("build", "run"))
+    depends_on("python@3.6:", when="@4:", type=("build", "run"))
     depends_on("py-flit-core@3.4:3", when="@4:", type="build")
     depends_on("py-setuptools", when="@:3", type="build")


Test patch: