Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-248

Add firefly_client and ws4py as third-party packages for display_firefly

    XMLWordPrintable

    Details

    • Type: RFC
    • Status: Implemented
    • Resolution: Done
    • Component/s: DM
    • Labels:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            tjenness Tim Jenness added a comment -

            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.

            Show
            tjenness Tim Jenness added a comment - 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.
            Hide
            shupe David Shupe added a comment -

            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?

            Show
            shupe David Shupe added a comment - 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?
            Hide
            tjenness Tim Jenness added a comment -

            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.

            Show
            tjenness Tim Jenness added a comment - 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.
            Hide
            shupe David Shupe added a comment -

            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.

            Show
            shupe David Shupe added a comment - 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.
            Hide
            shupe David Shupe added a comment - - edited

            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.

            Show
            shupe David Shupe added a comment - - edited 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 .

              People

              Assignee:
              shupe David Shupe
              Reporter:
              shupe David Shupe
              Watchers:
              David Shupe, Gregory Dubois-Felsmann, Loi Ly, Tim Jenness, Trey Roby, Xiuqin Wu [X] (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Planned End:

                  Jenkins

                  No builds found.