Consider merging with scientific-python template

DiamondLightSource / python-copier-template

Replacing Diamond Light Source's python3-pip-skeleton using Copier

Apache License 2.0

3 stars 2 forks source link

Consider merging with scientific-python template #150

Open danielballan opened 2 months ago

danielballan commented 2 months ago

In May ~2024~ 2023, NSLS-II and scikit-hep merged their templates and associated development guides into one template and guide, under the scientific-python org. We have seen advantages in maintenance: with shared effort, the shared template is staying better up to date. Our opinions and use cases are not perfectly aligned, but we have been able to find rough consensus on technology choices, and so far we find the benefits of sharing to be higher than the costs.

Let's explore whether it would make sense to merge the DLS/Bluesky copier template into this. Initial questions:

What technology/layout choices differ between them?
What would it take to provide facility-specific defaults during set up, so that a new user can mostly just press <Enter> and get the appropriate license file and other facility-local settings? Even if this required an enhancement to copier itself, that could be doable.

callumforrester commented 2 months ago

I'm supportive of finding something that we don't have to maintain ourselves :)

Should also think about:

Migration path for existing repos
Licence (ours is what our legal department tells us it is)
Generally what is considered mandatory/recommended/optional in the scientific python template

coretl commented 2 months ago

I'm cautious of making yet another change to DLS repos, but would be happy to move the copier template in the direction of the scientific python template to the point it was just that template with some opinionated defaults.

I think copier has the concept of meta templates, but I don't know precisely what they are, or whether they help us to make an opinionated template out of a generic template

The other issue with the scientific python template is that it has so many options I would be scared of touching it for fear of breaking something, I made the CI for ours reasonably tested in the template repo itself, which is a lot easier with an opinionated template

danielballan commented 2 months ago

That makes sense to me. I think it's too early to say whether merging is a good idea. At this point I would only argue for investigating what the costs of merging would be. Changes on the scientific-python side to facilitate this, including simplification or tested support for meta templates, can be on the table.

danielballan commented 2 months ago

FYI @henryiii