A bunch of us on the Sims team recently tripped over the fact that EUPS 1.5.9 handles third party packages differently than did earlier versions. We further tripped over the fact that we don’t know how to update EUPS without re-running newinstall.sh (and thus getting a completely new stack). Does documentation exists somewhere for updating EUPS in-place?
While I’m not sure what the official process for upgrading EUPS is, I would expect that rerunning newinstall.sh with EUPS_VERSION set to the desired version to achieve what you are describing (after refreshing the shell’s env). What was the failure mode?
I’m not aware of anyone who tried to update EUPS (we all just did a fresh install), so there is no “failure mode” to report. I will experiment with running newinstall.sh in an already extant stack.
This must be a change in eups distrib, not eups (I know, I keep making this point). It could be a problem in Mario’s eupspkg.
You can use git to upgrade eups as:
git clone git@github.com:RobertLuptonTheGood/eups
cd eups
./configure
make
make show
setup -r .
Pay attention to the make show output before you run make install.
git clone git@github.com:RobertLuptonTheGood/eups.git
cd eups
./configure --prefix=/path/to/packages/eups/someVersionName --with-eups=/path/to/packages
make install
Then you need to source /path/to/packages/eups/someVersionName/bin/setups.sh (or the corresponding file for your shell flavor).
Hi Scott
I’ve seen this claim been made a number of times – that something in EUPS changed the handling of external packages – but when I asked for details nobody could ever give me any. EUPS doesn’t differentiate between internal and external packages; it’s all just packages to EUPS. Are you sure you’re not talking about the switch of lsstsw from Anaconda to Miniconda (which has nothing to do with EUPS)?
Regarding updating EUPS, Paul’s answer is the correct one if you want to install from master (it’s a standard ./configure recipe). If you want a release, then download the desired tarball, untar, and install as above. Example:
wget -O eups-2.0.1.tar.gz https://github.com/RobertLuptonTheGood/eups/archive/2.0.0.tar.gz
tar xzf eups-2.0.1.tar.gz
cd eups-2.0.1
./configure --prefix="...where-you-want-it-to-go..." --with-eups="...where-the-stack-is..."
make
make install
If you’re interested in updating an existing lsstsw's EUPS, you can use:
EUPS_VERSION=2.0.1 ./bin/deploy
(from your $LSSTSW directory). That’s a convenient one-liner to just run the steps above, installing into $LSSTSW/eups/$EUPS_VERSION and symlinking $LSSTSW/eups/current to it.
And as @timj points out here, you can also use a git SHA1 to install a version that hasn’t been tagged yet.
You can use this to switch to an older version as well, i.e., running
EUPS_VERSION=1.5.9 ./bin/deploy
will detect that 1.5.9 is already installed (otherwise it’d go ahead and install it), and will re-point the $LSSTSW/eups/current to it.
(see the post above if you’re not using lsstsw!)
1 Like
I am going to go out on a limb here and guess that @danielsf is referring to packages that include a .tap_package file. Support for this was added in EUPS v1.5.8 and more importantly a couple of packages recently added to the stack use the tap_package file.
Yes. That is the error we have been seeing.
Ah, OK – that predates 1.5.9, that’s what was confusing me.
Btw., I now that I look at this, I regret agreeing to merge that PR – the requested feature already existed, I just forgot about it (argh!!). One could’ve set TAP_PACKAGE environment variable in eupspkg.cfg.sh (not in the table file, as the related JIRA issue mentioned). I think neither @ktl (excusably) nor I (inexcusably) realized that.
I’m thinking about doing a PR to revert to the old method (which would make future releases compatible with older EUPS-es again), while temporarily keeping the compatibility with the .tap_package file as well.
Doh! I don’t know why I was so fixated on table files for setting this. Reversion is fine (I presume you’ve tested the original?).
Yes, it did get reverted on Jan. 19, and it was then incorporated into 2.0.1.
Reverted is a too strong of a word – both methods now work (setting TAP_PACKAGE in eupspkg.cfg.sh as well as the deprecated .tap_package marker file). The .tap_package file support will likely be removed in a future version of EUPS.
What to do:
That would be stsci-distutils and python_d2to1. I think with pyyaml we decided that we have to keep both schemes around for a while so I think you are asking for the two packages to have TAP_PACKAGE set and not to remove the .tap_package yet.
Yup, that looks like the complete list (at least as of w_2016_10). Easier to fix than to file a ticket 
All future packages should set TAP_PACKAGE in eupspkg.cfg.sh [etc]
Where’s the documentation for all this? It seems like we’re setting policy for undocumented (except in the source) EUPS features, and not documenting that anywhere other than forum posts, and that’s scary.
No idea. The whole .tap_package thing was only pointed out to me by @KSK when I tried to add a README.md file to an EUPS third party package.
It seems EUPS does not include documentation for eupspkg so I assume you are suggesting we add something to our docs at http://developer.lsst.io/en/latest/build-ci/third_party.html?highlight=eupspkg
Do you want to file a ticket on that?