I’m trying to install the package
obs_cfht via EUPS without success. After successfully installing
lsst_apps, I try the command:
eups distrib install -t v12_1 obs_cfht
and I get the error message:
eups distrib: Trouble reading manifest for obs_cfht 12.1 (generic): First line of manifest file /tmp/eups/distrib/obs_cfht_dNuuET is corrupted:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
I noticed that there is an entry:
obs_cfht generic 12.1
in https://sw.lsstcorp.org/eupspkg/tags/v12_1.list but there is indeed no manifest for
obs_cfht in https://sw.lsstcorp.org/eupspkg/manifests/.
Since there are manifests for other
obs_* packages I’m wondering if the absence of manifest for
obs_cfht is a packaging bug or if it is due to the fact that this package is not yet fully integrated to the stack.
In case it matters, installation of
conda does not work either.
obs_cfht was removed from
lsst_apps 18 months ago, apparently out of a desire not to have to download the testing data. I wonder if, now that we’ve got Git LFS working routinely, if we might not revisit that? I would encourage you to file an RFC for including obs_cfht again.
Thanks Paul. I understand that
obs_cfht is not included in
lsst_apps, but I assumed one should be able to install it via EUPS. Currently installing it via
eups distrib install is not possible.
My understanding is that the inclusion of
lsst_apps will be possible after some issues such as DM-7309 will be solved.
I’m happy to submit an RFC for inclusion of
I believe DM-5661 is relevant.
In particular, I think it would be possible to tag and release obs_cfht and other relevant packages on a weekly (or whatever) cadence without adding them to lsst_apps.
Personally, I’d prefer that (albeit not strongly) to increasing the number of packages pulled in by _apps.
@swinbank you would have to add them to lsst_apps, as it is the only thing that can guarantee a consistent build, no? (Aside from the implementation detail that the git tagging is using the eups manifest file, but it is for the reason given). Otherwise how would you know what to tag?
If that’s possible, I’m fine with that solution. As a user, my end goal is not necessarily to have
obs_subaru, etc.) within
lsst_apps, but to be able to install the appropriate version of
obs_cfht which is compatible with an officially tagged version of
lsst_apps, be it a weekly tag or a stable release tag.
Currently what we do is to install
eups distrib install ... and then install
obs_cfht by cloning the github repo and building from source. This mechanism kind of works but is extremely fragile: you have to know exactly what commit of the master branch of
obs_cfht is compatible with what version of
lsst_apps. If you are not a developer with intimate knowledge of the stack, this is far from obvious.
As a user of the stack, I would like to be able to do, say, install the version
obs_cfht compatible with (i.e. automatically tested against)
lsst_apps v12_1. The solution to this may be including
lsst_apps or any other mechanism that the experts of the software packaging may suggest.
Having noticed that there is a tag
obs_cfht I thought I could do:
eups distrib install -t v12_1 lsst_apps
eups distrib install -t v12_1 obs_cfht # this does not work
which was the trigger of this conversation.
This sounds bizarre to me, but I defer to your expertise on the build system.
I think what would be needed is for the weeklies to be based off a build that just adds
obs_cfht to the list of products (you can add any products to the build along with
lsst_apps). I can’t see why that would not work within @frossie’s system (is there a reason the weeklies aren’t publishing
RFC submitted: https://jira.lsstcorp.org/browse/RFC-251