Merge with / deprecate in favor of scientific-python/cookie?

[nstarman]

https://github.com/scientific-python/cookie is the cookie frontend to the excellent https://learn.scientific-python.org/development/ resource. It's more actively developed and more fully featured. Rather than duplicating effort, should we upstream the best parts of this packaging guide to https://learn.scientific-python.org/development/ and https://github.com/scientific-python/cookie and then deprecate this repo?

(Note: also impacts https://github.com/astropy/astropy/blob/main/docs/development/astropy-package-template.rst)

[Cadair]

The philosophy of that guide / template and this one are very different. I think there's space for both.

The goal of this template was to make a template that has opinions and provides one way of doing things, with a few optional features. This means this template does not have "Eleven different backends to choose from for building packages." it has one, the same one used by Astropy and SunPy.

I do not believe that scientists trying to setup a astropy or sunpy affiliated package want or need a choice in build backend (for example), and just want to get something which is "the same as" other things they might look at.

[nstarman]

I'm perfectly happy with there being space for both package templates, but I must admit I have yet to see the evidence.
To me, the example of the plethora of build options in the other cookie while this cookie only supports setuptools is something I would have used as an example for why we should merge the two efforts. For several years now the well documented best practice for pure Python packages has been to NOT use setuptools. Hatch is usually better. For large projects that need to build C code the scientific Python community is switching to Meson. Astropy should eventually as well as we want to be consistent with the ecosystem. So again we probably shouldn't be getting new packages started with setuptools. For some projects setuptools is best, but the point is that it often isn't. And even for starting a project that is meant to be in the Astropy ecosystem setuptools isn't the obvious choice. So I would have used this example as a reason why we should consolidate efforts.

[Cadair]

I disagree that setuptools is a bad thing to be using, but this isn't the forum for that discussion.

To some extent I don't care what tool this repo uses, but I do firmly believe it should make that choice for the user. If the first thing the open astronomy / astropy or SunPy guides have to start with is "pick a packaging tool" we have gone very wrong. Also I think that this guide should do the same thing as astropy and sunpy, so we should migrate those to a different tool in tandem with this repo.

[nstarman]

A Q:

but I do firmly believe it should make that choice for the user. If the first thing the open astronomy / astropy or SunPy guides have to start with is "pick a packaging tool" we have gone very wrong.

I agree it should offer a sensible default! scientific-python/cookie has Hatch as the default, since it is the packaging.python.org recommendation and most projects are pure Python.
But I'm not sure it's so wrong to offer a choice, particularly if a user's needs are different.

Also I think that this guide should do the same thing as astropy and sunpy, so we should migrate those to a different tool in tandem with this repo.

Fair enough. 👍

I guess my larger point, beyond choice of backends, is that I worry about the multiple reproductions of effort and the decoupling of Astropy etc from the rest of the scientific python ecosystem. First, Astropy doesn't actually use this repo as its base so there's already a doubling of effort to keep this repo up-to-date with Astropy. Second, there are a number of ways the scientific python ecosystem is evolving that Astropy is starting to move to follow, from build backends to testing frameworks. The move to keep Astropy consistent with the scientific python ecosystem is fantastic, but the closer we are the definitionally smaller difference there is between this repo and scientific-python/cookie. IMO we move to strengthen both repos by adding the best bits of this one to that one and don't duplicate efforts going forward. There's been a lot of discussion Astropy-side about the time spent on infrastructure. While my opinions are somewhat different (I see upgrading Astropy to use the current Python best practices and scientific python community-specific practices as a good thing), I wholeheartedly agree that we should minimize time spent. Which is one of the reasons I opened this Issue.