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.

[PJ-Watson]

Following up on this - a couple of updates from my end:

• The Makefile's been updated to follow the same version scheme as the Python package (previously pinned to v1.0.3!).
• I've gone over the C library and added those tests to the automated github actions (+py3.13), so any future regressions or platform-specific errors should be caught before release.
• I've added a page to document any changes to the public C functions, almost all of which are int -> int64 in some of the function parameters (see issue #122 and gbrammer/sep).

I've sent another email to @kbarbary - I'd forgotten that I'd already tried sending one last year before forking this repo. However, I can only see the one email address shared across Github, PyPI, and the package notes, and it doesn't look as though he's active on Github anymore. My feelings on this are that if I still haven't heard anything by the end of next week, then I'll go ahead and file a PEP 541 request to transfer the name. It doesn't look as though that'll be a particularly quick process, but I can't really see any alternative if we can't reach the original author.

[olebole]

It looks that with the creation of the @sep-developers organization and the transfer of this repository this is resolved now?

@PJ-Watson @kbarbary thank you so much for your understanding of the problem and your cooperation! I am very glad to see this perfect solution!

[kbarbary]

Just wanted to say thanks for your packaging work @olebole and @sergiopasra! As I discussed with @PJ-Watson privately, I have been out of astronomy for about 7 years now. Despite my best intentions, I have obviously not kept up with maintenance of sep the last few years; my sincere apologies for the radio silence. It's long past time that someone else took over. I'm really glad to see SEP continue development under new leadership!

[martinberoiz]

Thanks @PJ-Watson and everybody else for keeping this project afloat! There's quite a bunch of projects depending on it, y'all know how this works.

[olebole]

As this is resolved now, I am closing it. Thank you for all participants for the help!