Please consider following SPEC0

[hmaarrfk]

https://scientific-python.org/specs/spec-0000/

Python 3.10 should just be dropped.

This simplifies things like click having two different version constraints.

The conda package needs reworking because of this.

Or…… or can drop Python 3.10.

If you don’t want to consider it. Then please just say so. And feel free to close this issue.

[stefanv]

Please see #287 for general Python support policy. We have a more conservative approach for spin than for other packages, because it is used in the build system.

The reason that that version constraint exists is because there is some enum-related bug in Python 3.10 that breaks one version of click. For conda, it would be totally fine to just set a more conservative click constraint for all versions of Python.

[hmaarrfk]

I was really hoping this wasn’t going to come from one of the authors of spec0.

Build system or not. Just sunset things with SpEC0.

You are not helping maintainers (including yourself) by increasing the test and surface area.

I’ll let you update the conda package if you care about it.

[stefanv]

We've had this conversation in the ecosystem many times, but the SPECs are recommendations and not prescriptions. They are meant to give developers freedom to move ahead and drop versions, and not feel like they have to support older versions forever. If a package wants to do the work of maintaining backward compatibility, that is fully within their right. If a distribution, such as conda forge, prefers not to distribute for any given version of Python, that's totally fine by me.

The Python support here is akin to scikit-learn doing LTS support (longer window than SPEC0). This is entirely compatible with the way the SPEC is written.

As you can see from #287, there was a request from a package using spin that we hold off on dropping Pythons that are not EOL. If this was onerous, I would probably not have considered doing so, but it really has not caused much difficulty thus far.

[hmaarrfk]

We have to lead from the front.

And not give recommendations that we refuse to follow ourselves.

If everybody claims an exception. Or asks for some kind of extended support. Then it just puts undue burden on the developers giving their time.

The only way to demonstrate that SPEC0 has any value as a recommendation worth reading by non authors is to demonstrate that the authors themselves are willing to use it to justify hard decisions.

I do believe in SPEC0s value. This is why I continuously bring it up. However. It seems that the authors do not. Meaning it is loosing strength as a tool to suggest to others for me.

IMO People that use Python 3.10 today are perfectly fine with Spin 15. They have their packages. They are built. They have found workarounds.

[stefanv]

The SPEC is meant to protect the maintainers of a package, and I'm the maintainer of this package. There's a reason I adopt the SPEC0 policy eagerly for scikit-image: because that package is hard to build and maintain for multiple Python versions. This one is not.

Can we please bring the conversation back to pragmatic concerns: what problems were created here by supporting older Python versions, why were those problems hard to work around, etc. It's not like the rules are set in stone, but if we can't discuss them in a civil manner, I don't think we're going to make much progress.

@zklaus Perhaps it would be helpful to also hear from your perspective why it was useful to continue supporting Python 3.9. If we changed that policy to align with SPEC0, what obstacles will be introduced for your projects? If the answer to that question is "none", then the whole conversation is moot.

[hmaarrfk]

The pragmatic concern is that conda recipes don’t have a simple way to express different dependencies for different Python versions.

Perhaps you don’t care for conda, there are many reasons not to care for it including the increased support burden.

But for me, the note about deep copies and developer time spent on troubleshooting things is more than enough to say « let’s drop Python 3.10 ».

The practical concern. Is that this shouldn’t be an issue because of the SPEC0 and NEP29 you were involved in. However. For some reason. We are still having this discussion.

If we were speaking about eagerly dropping 3.12 due to some increased burden I would understand.

But like I’m just tired of these discussions. The goal of SPEC0 is to drop things like 2 lines of code in a configuration file to simplify things. These lines accumulate.

These discussions get repeated.

And more of our personal time (it’s quite late where you are) is spent on requirements that don’t exist.

[hmaarrfk]

I was honestly expecting « oh that was an oversight. We can even drop 3.11, lets make a new release to fix this »

[stefanv]

Right, but it wasn't an oversight: it was an agreement to accommodate a user's request. And I cannot just turn around on my promise without doing the necessary work to uncover the relevant needs and limitations.

I didn't know that conda recipes cannot express different dependencies for different Python versions—thank you for that information. I will certainly bear that in mind in the future.

Python 3.10 is EOL 2026-10, so then the problem goes away (I hope). There are at least three options available to us now:

1. Drop Python 3.10 support right away (I'd like to hear @zklaus's thoughts first)
2. Drop Python 3.10 support on conda forge right away (is this possible, Mark?)
3. Add a workaround for the 3.10 enum bug in Python 3.10 — this, I am unwilling to put time into.

[rgommers]

These discussions get repeated.

You're the one repeating it here. Speaking as another author of NEP 29 and SPEC 0: you are seriously misunderstanding the guidance in those docs. With all do respect: please stop bringing these documents up as if they're prescriptions that must be followed.

It's very very simple here: important package wants to use spin and has a "we support all non-EOL Python versions". Hence, spin decided to do so too.

Drop Python 3.10 support right away

I can answer that: no, please don't. The current policy is the right one for spin (and I think for all build/dev tools in general).

[hmaarrfk]

All good with me. It’s your project. Do with it as you please.

I won’t bring it up again.

[stefanv]

All good with me. It’s your project. Do with it as you please.

I don't really like for conversations to end like this, Mark. I want to find ways to accommodate the different concerns and I appreciate your inputs. You and I have worked together for a long time, and I hope to continue doing so. The conda forge package is worse off with you removing yourself as maintainer, but I also understand the burden of maintaining so many ecosystem packages (thank you for all the work you do!).

[hmaarrfk]

All good with me. It’s your project. Do with it as you please.

I don't really like for conversations to end like this, Mark. I want to find ways to accommodate the different concerns and I appreciate your inputs. You and I have worked together for a long time, and I hope to continue doing so. The conda forge package is worse off with you removing yourself as maintainer, but I also understand the burden of maintaining so many ecosystem packages (thank you for all the work you do!).

Thanks for this note. This conversation didn’t sit well with me last night

Let me gather my thoughts and come back to you. It will take time for me to write this down.

[hmaarrfk]

I want to share my thoughts and interpretation about SPEC0 and why I think it is really important that the endorsing project follow it strictly.

While I wasn't involved in the drafting of SPEC0, I have been reading it over the last few months
to help justify where to spend my time as a maintainer of OSS.
https://scientific-python.org/specs/spec-0000/

I am really trying to read and interpret it as written. Apologies if I misinterpret

This SPEC recommends that all projects across the Scientific Python ecosystem
adopt a common time-based policy for dropping dependencies. From the
perspective of this SPEC, the dependencies in question are core packages as
well as older Python versions.

To me, this doesn't carve out any exception for "foundational" packages like
numpy or spin. In fact, numpy, and the scikit-image, whose core devs wrote the
spin package, are listed as authors and endorsers.

All packages, means to me, "all".

The motivation of the SPEC really resonated with me.

reduce the need for individual projects to divise similar policies.

Ultimately, reduced maintenance burden frees up developer time, which
translates into more features, bugfixes, and optimizations for users.

As somebody who helped in
the Python 2->3 transition of scikit-image, I learned that "smooth" software
transitions are fundamentally hard. Long support tails are even harder.

While I don't really want to get into the specifics, in the case of SPIN, there
is a directly measurable cost o this "discussion":

1. A version upper bound was added to SPIN's dependency (click) to work around Python 3.10. Python 3.11+ do not have this upper bound on click.
2. I raised an discussion point
3. A core maintainer (who's time i greatly value) spent time finding the source fo the decision.
4. I reacted poorly (i apologize). My intentions were to avoid more back and forth rethinking an other developer's good intentions.
5. I decided, that as an OSS contributor I did not want to consider these tradeoffs between old versions and python and the software landscape of 2026.
   • I think this shouldn't be dismissed. In my mind, many OSS contributors are volunteers.
     Their time is valuable. If they have to spend time thinking about
     tradeoffs that SPEC0 is meant to avoid, then the SPEC is failing in its purpose.
6. A PR was opened to add an upper bound to all versions python + spin 0.16. This did not get caught through the review process.
7. Users of Python 3.12+ (listed as explicitly supported by SPEC0 as of Jan 2026) now are bound to and old version of click.

This chain of events, which could have been avoided if the SPEC0 was followed
strictly, users of Python 3.12+ have a sub-par experience with SPIN.
(PR conda-forge/spin-feedstock#20 if you want to review a what I consider a more appropriate fix)

Perhaps this can be resolved at the conda level, perhaps we can find the source
of the bug at the SPIN level, or within click itself, but my interpretation of
SPEC0 is that it is meant to avoid this kind of situation.

While it seems tempting to make exceptions for foundational packages, I think that
it is really important to follow the SPEC0 as written, for all packages, to avoid
these kinds of situations in the future.