Error installing obs_cfht (via EUPS)

Support
,
#1

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 obs_cfht via conda does not work either.

#2

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.

#3

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 obs_cfht into 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 obs_cfht into lsst_apps.

#4

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.

#5

@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?

#6

If that’s possible, I’m fine with that solution. As a user, my end goal is not necessarily to have obs_cfht (or 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 lsst_apps using 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 obs_cfht to lsst_apps or any other mechanism that the experts of the software packaging may suggest.

Having noticed that there is a tag v12_1 for 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.

#7

This sounds bizarre to me, but I defer to your expertise on the build system.

#8

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 lsst_distrib?)

#9

RFC submitted: https://jira.lsstcorp.org/browse/RFC-251