If firefly_client will be changing regularly or getting LSST-specific fixes locally before pushing upstream, you can use the xrootd and oorb approach to eups packaging: forking the repo to LSST org and using an lsst-dev branch in the fork with the ups support directories and the like.

Tim Jenness I like this forking approach. Would firefly_client need to be in its own repository for it to work? The answer seems "yes" to me but I'd like to make sure. At the moment it is inside the firefly repository.

There is a firefly repository already at https://github.com/lsst/firefly but I believe it will be abandoned, and it does not look like a fork to me. Should we consider forking the entire firefly repository instead?

I think the firefly LSST repo is an old experiment that allowed the code to be available whilst internal IPAC issues were sorted out allowing the code to go truly public. I don't think we really gain by forking firefly into LSST org just to get firefly_client because the lsst-dev branch would have to understand that the EUPS package was not the entirety of firefly.

I had not realised that firefly_client was not in a standalone repo, but a standalone repo would be the preferred way for this forking scheme to work.

Tim Jenness Putting firefly_client in its own repository was raised in DM-7464. It was tabled since the pip-installable part could be done separately (and was done in DM-8007).

Let me discuss this with the SUIT team next week when people are back from travel.

SUIT has decided to move firefly_client to its own repository to enable forking the repo to the LSST org as suggested by Tim Jenness.