Split out a new section Archived/emeritus for affiliated packages

[hamogu]

The original intent (at least in my mind) for affiliated packages was to provide the community with a list of high-quality, actively maintained packages for their needs in astronomy. After many years, we have a large number of affiliated packages (good!) and some of them are no longer active, e.g. they have been archived in github by their maintainers. Yet, some of these packages are still used widely and perform well, at least if installed in environments with older Python versions. Thus, we don't want to remove them from the list, but we also want to distinguish them in some way.

Here, we split them out into a new section.

This was discussed at the 2025 Astropy Coordination meeting, but is a variant of of the ideas mentioned in the discussion.

[hamogu]

This needs comminity discussion, but I encourage @dhomeier to take a look first before we send it to the mailing list.

[pllim]

Thinking ahead: When packages in post-APE 22 get sunsetted as well, how do you envision this listing would look? Will it be too confusing to have yet another section for those?

[hamogu]

We'll have to see what pyOpenSci does, will they add a "deprecated" tag to their listing that we can pick up? Or will they just be removed? In that case, we would add them manually to our section.

But honestly, I think we are getting ahead here. We've had the "affiliated" packages for over decode and only now this comes up. We don't know the state of astropy or the Python packaging ecosystem a decade from now, so I think we should't worry about that too much right now. We need a few cases where that actually happens to see what will work - and those cases are likely years away.

[pllim]

Does this mean we should revert this PR

• Remove saba from the list of affiliated packages #676

and add SABA to "archived/emeritus" instead?

[hamogu]

No, the "archived/emeritus" in my view is for packages that are still useful and still used, but not updated anymore - not a historic list of everything that ever was. For example, to the best of my knowledge, there is no other package that provides the capabilities of e.g. omnifit or polioastro. So, if I want to use that, I might just have to be prepared to install an older numpy version (I didn't text is, but I suspect that the numpy 1->2 transition might trip up some of the older packages). On the other hand, I don't see a use case where I would recommend saba (#676)at this point. Some of the capabilities that Saba was meant to provide from sherpa are now in astropy.modelling itself (independently developed thanks to all the recent work on that package), others are better brought in through other interfaces or packages (e.g. optimagic provides a much larger range of optimizers than Sherpa does).

That's not a decision we affiliated package editors want to make; it's best left to the package authors if they are still responsive. In the case of #676 the current maintainer of Saba (who happen to be me) made the request to withdraw it. However, for truly abandoned packages at some point the astropy affiliated editors might have to decide that the time has come to remove a package from the listing entirely. A "re-review" was always part of the original vision for astropy affiliated packages (I would have to dig through the git history to find the old wording), which means that the editors have the power to order a re-review and reject (i.e. remove) a package. I would argue that in obvious cases (say a package that is archived, does not work with any Python version released in the last decade and whose functionality is superseded by other packages) editors should make that decision themselves; in other cases they may ask for reviewers to look at the package.

[hamogu]

Suggested change

	<p>This section contains a list of packages that are no longer actively maintained, that means that they might
	no longer work with the most recent release of Python or Astropy and do not receive new features or bug fixes.
	However, some of those packages still provide unique
	capabilities that no newer package matches or are still widely used.
	<p>This section contains a list of packages that are no longer actively maintained (so they might
	no longer work with the most recent release of Python or Astropy and do not receive new
	features or bug fixes) but are still widely used or provide unique
	capabilities that no newer package matches.

[pllim]

I think the line of reasoning at #679 (comment) needs to be documented somewhere easier to find for future Editors. Maybe here?

https://github.com/astropy/astropy-project/tree/main/affiliated

[hamogu]

Good idea! But since it's in a different repro, let's discuss here first and if we agree that this is the way to go, we can make corresponding updates in astropy-project.

[pllim]

I trust the current Editors to have sound decisions in this matter, so it is up to you and @dhomeier . Thanks! :)