astropy
Scope out how we want to template using existing tools and what it gives the community
Came from a breakout in the 2023 Coordination Meeting (including me, @hamogu, @pllim, @weaverba137, @saimn, @aaryapatil).
Tied to ~an astropy/astropy.github.io~ https://github.com/astropy/astropy.github.com/pull/523 ~issue I can't immediately find~ about removing the package-template maintainer role.
There's a fair amount of disagreement whether or not the problems the package-template solved are fully solved by the OA template. That is, the OA package template is meant to address the same technical problems, but the outreach elements, and making sure the astropy user community doesn't struggle too much with packaging, aren't necessarily all under OA's umbrella. But maybe it is?
Given that uncertainity, we agreed @weaverba137 and I should try to write a short document akin to a requirements document to say what we think the purpose of the package-template was/should be, and then @pllim and @hamogu will review that and potentially disagree.
Because I know they've had opinions on this in the past, also pinging @astrofrog and @Cadair, although they may or may not want to be involved at this "write the document" stage as opposed to a stage after the first iteration of it.
I'm interested in being kept in the loop.
I'm not sure where the right place is to write this, but to provide the flip side of the coin, but the main motivation for developing the OA guide (which isn't finished) was that one of the issues with the astropy package template is that it does not really do much to educate users of the template as to why various things are done, and often ended up with some files with a bunch of commented out code or code that wasn't really needed so we wanted to write a packaging guide that happened to have a template rather than making the template the main focus, to really encourage users to read the docs, and have more of the things be opt-in so that the simplest template would be minimal. The OA guide at the moment is not quite complete, and we always intended to add back information about some of the astropy and sunpy-specific things (e.g. use of astropy.config and so on).
I think we may want to also make sure we have a dedicated call about this, maybe we could allocate one of the infrastructure calls to this.
I have never used the template so just a different opinion: Python packaging is evolving quite fast, compared to 10 years ago there are now nice guides (e.g. https://packaging.python.org/, https://www.pyopensci.org/python-package-guide/index.html), many new tools (pdm, hatch, poetry, ... and lots of discussions currently on avoiding having too many of them) with which you can just run <tool> init to get started, etc.
So question is, do we still need a package template for Astropy, or for Astronomy ? What's specific and justifies the effort ?
I use the same tools/structure for my astro and non-astro packages.
Education is still an important part, but with (recent) initiatives such as https://www.pyopensci.org/python-package-guide/, do we need more than that ?
I have since retired package-template, so I changed the title above.
Also see discussions here:
- https://github.com/astropy/astropy/issues/11621
Leah started pyOpenSci discussions here:
- https://pyopensci.discourse.group/t/moving-towards-shared-vetted-community-packaging-resources/353
hey y'all - wanted to also mention that we're working on tutorials and such around packaging. right now we've having monthly writing sprints and people are providing feedback on new pages in our guidebook and the tutorials which will eventually be online.
Where we can we'll use other content for instance plasmapy has some great content that we can use the credit them for writing @namurphy discussed this (i would never just borrow content without linking back, providing credit and asking of course). ideally we can then have some great resources that are specific to the scientific community and vetted by that same community.
Since Astropy itself does not maintain a template anymore, I don't think we need to pursue this as an org.