Archiving this repository and making PJ-Watson/sep-pjw the primary one?

[olebole]

I am the Debian maintainer of "sep", which also serves as a dependency for the astroalign package by @martinberoiz. Recently, astroalign switched this dependecy to sep-pwj, which aims to be a compatible, maintained replacement.

This, original, repository seems to be unmaintained since 2022. I would therefore like to switch to the one from @PJ-Watson for the Debian package. This would however suggest that the sep-pjw package "hijacks" the original "sep" package name to make the transition easy, and this would (IMO) suggest that the "official" development moves to the sep-pjw package. This would be great in any way to avoid fragmentation of development.

Therefore I would propose to archive this repository (set it to read-only) with the hint to migrate to sep-pjw.

@kbarbary @PJ-Watson, what do you think?

[PJ-Watson]

Hi Ole, I'm generally in favour of this. The package name change was the only way to avoid conflicts when uploading to PyPI, but I'd much rather avoid fragmenting the package further, or duplicating any other efforts to maintain this.

The only slight concern I'd have is regarding the compatibility of the C API. All the changes I've made are backwards compatible with respect to the Python interface, but I'm not sure this is the case for C - e.g. the sep_image struct now contains information on any existing segmentation map (c.f. SExtractor dual-image mode), and various int have been changed to int64_t (hopefully fixing #122). Looking through previous releases, it does seem like there have been similar changes before (e.g. v1.0.3->v1.1.0), but I'd need to double check and signpost where any incompatibilities might arise, before merging the package names.

One other thing to mention is the python version support. sep-pjw is currently tested against Python 3.9-3.12 (although I'll extend that to 3.13 in the very near future). In general I'd prefer to follow NEP 29 for supporting older Python versions in future releases. However, since there's been such a long time since the last "sep" release, if we change the package name, I'll keep the current support as is for a while, to avoid any dependency gaps with the various NumPy versions.

[sergiopasra]

Hello, I'm the Fedora maintainer of "sep", and I agree with with what @olebole mentioned before.