The display_firefly backend for afw.display depends upon the lightweight firefly_client Python API for Firefly. firefly_client in turn has dependencies on ws4py and future. This request is to add firefly_client and ws4py to the stack as eupsified packages.
firefly_client has been residing in the https://github.com/Caltech-IPAC/firefly repository (specifically here) and has been made pip-installable. It is being moved to its own repository here. This will enable forking the repository to the LSST organization.
- is triggering
DM-8295 Implement ws4py as third-party package installable by eups
DM-8296 Make fork of firefly_client installable by eups
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.
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.