Installing packages without write permission

Data Management
#1

Hi DM experts,

As a new user, I am facing a situation where I’ve been pointed to centrally managed versions of the DM stack where I don’t have write access (e.g., weeklies at Lyon or installs at SLAC). I’ve been facing the situation where there are packages that I need that are not installed centrally (the most important example being lsst_sims). If I were pointing at my own version of the stack I would solve this problem with a eups distrib install; however, on centrally managed stacks I generally do not have write access. I’ve faced a similar problem before in other non-lsst environments, I’ve been able to cobble together a solution by installing my own version eups, prepending its path to my $EUPS_PATH, and using the --nolocks --no-server-tags options for eups distrib install.

So far, I haven’t been able to get a similar solution working with the DM stack. I was wondering if anyone else had solved the problem of installing on top of write-protected central installs.

Tagging @johannct, @heather999, @ljones, and @rhl since we’ve started to discuss this on slack.

#2

I think this should just work with master eups (which @timj may have just tagged). I fixed a couple of issues for @FabioHernandez and I think he’s been happy since.

I don’t think you needed to install your own version of eups; simply putting a writeable directory (containing a possible-empty ups_db directory) to $EUPS_PATH should be enough.

With master eups the --no-server-tags option will still install any tag you specify with -t but be quite a lot faster on startup (there’s a problem with people using robots.txt files).

#3

I don’t see a recent tag yet in https://github.com/RobertLuptonTheGood/eups. Is there any chance this version of eups will make it into the upcoming v14 release?
Thanks,
Heather

#4

v14 will be using eups v2.1.3 (it’s already being tested).

#5

Ok - understood. Just having a eups tag would be helpful, as I’d just update newinstall.sh to point to the new version.

#6

2.1.4

1 Like
#7

My first attempt failed. I’m sticking with w_2017_26 using newinstall’s provided miniconda3, as I believe that nfs fix (https://jira.lsstcorp.org/browse/DM-11771) isn’t available in a weekly yet (is it?). The only change is the move to eups 2.1.4, which I introduced by changing that one line in newinstall.sh to set EUPS_VERSION to 2.1.4.
I made it most of the way through building lsst_distrib but failed here:

 [ 100/101 ]  jointcal master-gc935ebf72c+5 ... 

***** error: from /nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/stack/miniconda3-4.2.12-7c8e67/EupsBuildDir/Linux64/jointcal-master-gc935ebf72c+5/build.log:

E
======================================================================
ERROR: setUpClass (__main__.UtilsBinaryTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/stack/miniconda3-4.2.12-7c8e67/Linux64/utils/13.0-6-g7b92220/python/lsst/utils/tests.py", line 198, in setUpClass
    raise Exception("No executables discovered.")
Exception: No executables discovered.

----------------------------------------------------------------------
Ran 0 tests in 0.001s

FAILED (errors=1)
The following tests failed:
/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/stack/miniconda3-4.2.12-7c8e67/EupsBuildDir/Linux64/jointcal-master-gc935ebf72c+5/jointcal-master-gc935ebf72c+5/tests/.tests/test_executables.py.failed
1 tests failed
scons: *** [checkTestStatus] Error 1
scons: building terminated because of errors.
+ exit -4
eups distrib: Failed to build jointcal-master-gc935ebf72c+5.eupspkg: Command:
	source "/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/eups/2.1.4/bin/setups.sh"; export EUPS_PATH="/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/stack/miniconda3-4.2.12-7c8e67"; (/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/stack/miniconda3-4.2.12-7c8e67/EupsBuildDir/Linux64/jointcal-master-gc935ebf72c+5/build.sh) >> /nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/stack/miniconda3-4.2.12-7c8e67/EupsBuildDir/Linux64/jointcal-master-gc935ebf72c+5/build.log 2>&1 4>/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3_2/stack/miniconda3-4.2.12-7c8e67/EupsBuildDir/Linux64/jointcal-master-gc935ebf72c+5/build.msg 
exited with code 252

I can provide the build log if it’s helpful. Is there an expectation that I should be using a more recent weekly to take advantage of this new eups?
Take care,
Heather

#8

The NFS problems should be fixed in the next weekly.

If you are not interested in jointcal then you can probably use this build since you most likely want lsst_apps.

That test error is interesting. It’s complaining that it didn’t find any executable tests implying that test_wcs wasn’t built. I haven’t seen that error before.

#9

FYI, my attempt to build the stack on Ubuntu 16.04 (ver. w_2017_33 and Python 2 though) failed with exactly the same error yesterday.

#10

Can you try _35 instead? Also see if it’s in py3.

#11

I’ll try. Though I was kind of surprised to see any errors. I built this particular version (i.e. w_2017_33) with Python 2 and 3 on lsst-dev a week ago with no problems at all.

#12

Ok I’ll try to carry on with this build, and toss in lsst_sims. That way we can carry on testing the new features offered by eups. I’ll just note that I’ve built this weekly of lsst_distrib successfully on the same machine without any complaints from jointcal. The only difference is my move to the latest eups.

#13

If you can demonstrate that repeatedly that would be really useful. EUPS shouldn’t have any impact on a particular build since none of the packages depend on EUPS when they are being built. If switching between 2.1.3 and 2.1.4 is the difference between jointcal building and not building then I need to investigate.

#14

I built a master version of jointcal fine. My guess is that if you were to look at _build.log it will show that the test_executables.py file is being executed before test_wcs.cc is compiled.

1 Like
#15

Hello! Today, I tried to install lsst_distrib, and jointcal failed with the same output as @heather999. Here are several details to consider:

  • I set installation with Python 3 (bash newinstall.sh -3)
  • Bootstrap installed EUPS v2.1.2
  • eups distrib install -t v14_0 lsst_distrib completed successfully until jointcal 14.0. The error is the same as noted above (No executables discovered)

[ 105/106 ] jointcal 14.0 failed. Just 1 step before the end :rage:

#16

Can you try building jointcal with a single thread/job (EUPS_SCONSFLAGS="-j 1" eups distrib install -t v14_0 jointcal)? That might allow you to work around a race condition.

#17

Setting number of jobs to 1 did not help, but opt=1 did (less agressive optimization). Now, all packages completed successfully.
(thanks to @darko )

#18

@parejkoj I wonder if we should be worried that jointcal was failing when optimization was enabled.

#19

I run jointcal with the default scons optimization all the time: it gives a factor of several improvement in speed.

What system is this being built on and what was the failure?

#20

OpenSUSE 13.2
The failure was the same as heather999 listed above: test failed, "No executables discovered."
Please see my previous post above.
Maybe it’s not directly related, but after setting opt to 1, the installation completed without errors.