Consider merging with scientific-python template

[danielballan]

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]

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]

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]

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]

FYI @henryiii