Hsin-Fang Chiang: this is a trivial change, but it still needs a reviewer...

Feels a bit weird that jointcal depends on obs_cfht.  obs_decam tests processCcd inside itself so this seems to do the opposite. I guess this is a better direction of dependency, rather than testing jointcal inside obs_cfht?

Jointcal's setupOptional requirement on testdata_jointcal is what most of the tests operate with, but I wanted to move a little bit of data (about 2MB) into jointcal itself, so it could run tests if the testdata package (1.5GB) wasn't available. Jointcal needs fully processed catalogs, so the existing testdata_X or validation_data_X packages aren't enough (like your example re: processCcd and obs_decam), because they contain raw data. Instead of trying to come up with some fake metadata and a fake focal plane model, I used something that already existed.

Eventually, I'd like to move to using obs_lsstSim for this sort of thing, but there isn't yet appropriate lsstSim data for all of jointcal (though the DC2 simulations might be it, once they are vetted).

Thanks for the quick review.

Since this done, I don't think we need to agonize over it now. However, I do share Hsin-Fang Chiang's doubts about this.

As far as I know, obs_cfht is only included in lsst_distrib by virtue of being part of the lsst_obs metapackage. That metapackage has an expectation that broken or difficult obs packages can be dropped from it without slowing down the rest of development (see the discussion on RFC-251). Having a core part of the stack depend on a “semi-supported” obs package feels like an unfortunate situation.

Until we have trivial test lsstSim test data that we can use in jointcal, I don't see a better solution, currently. DC2 may fix this, but I we won't know until later, and then we'll have to extract an appropriate chunk of it to be the test data.

If that works, I'd be more than happy to remove the obs_cfht dependency.