v12.0.rc1 does not work on Ubuntu 14.04 about lsst-cvmfs

[airnandez]

The contents of the file:

/cvmfs/lsst.in2p3.fr/software/linux-x86_64/lsst-v12.0.rc1/eups/bin/eups_setup

is

#!/usr/bin/env sh
# N.b. some (many?) unix systems don't understand
#  #!/usr/bin/env python options
#
unset PYTHONSTARTUP
/bin/python -S "$EUPS_DIR/bin/eups_setup_impl.py" "$@"

Note that line 6 uses the absolute path of the Python interpreter /bin/python which does exist on CentOS 7 where the binary was built, but not on Ubuntu 14.04.

[TallJimbo]

I believe that when /bin/python exists it's a symlink to /usr/bin/python, which is a much more reliable location (but perhaps later on the default path). If you want to use a system Python (and I don't understand why you are - is it just for EUPS installation?), then I think /usr/bin/python is a better choice.

[airnandez]

On the CentOS 7 box I use for building, /bin/python is indeed a symbolic link to /bin/python2. On Ubuntu 14.04, the Python interpreter is /usr/bin/python.

I don't want to use the Python interpreter shipped with the system, but the EUPS command eups_setup does and has the absolute path in it. On Ubuntu that path does not exist. In practice, that would mean:

• I build a specific version of the stack for Ubuntu and potentially other Linux distributions, or
• I ask Ubuntu users of this binary distribution to create a symbolic link to make /bin/python a symbolic link.

None of those solutions seem sustainable to me. I wonder if it would be possible for the EUPS eups_setupcommand to use just python instead of /bin/python.

[TallJimbo]

I suspect it should be using /usr/bin/env python (and perhaps used to), but that was changed to avoid SIP problems on OS X. Maybe @timj knows?

[timj]

I am shocked that anyone thinks it's a good idea to put python in /bin 😄

One problem is that this seems to be using an old version of EUPS and this was changed in RobertLuptonTheGood/eups@d7b10d1

@mjuric has not released a 2.0.3 yet.

It looks like the problem still exists though because EUPS burns in @EUPS_PYTHON@ as which python as part of the build process. I assume it does this so that once you have built your EUPS it won't break if people change their path later on.

[timj]

Oh, and the EUPS script was rewritten in RobertLuptonTheGood/eups@8be15ae to use a full path in the shebang.

@TallJimbo is correct that SIP leads to use not using /usr/bin/env on OS X but in theory the substitution of EUPS_PYTHON could differ on Linux and OSX if that would help.

[mjuric]

Is there a path to a Python binary that's identical on Ubuntu and RHEL? Would that solve the problem @airnandez is seeing?

[TallJimbo]

On all the Linux distros I've used, /usr/bin/python is available, and on all the Unix-like systems I know of besides El Capitan, /usr/bin/env python is preferred.

[mjuric]

@airnandez, could you see if using the EUPS version from current master solves your problem? We could quickly cut 2.0.3 if it does.

[airnandez]

From the limited test I was able to do, it seems to work. Specifically, I installed the current EUPS master from source, built it on CentOS 7 and copied the installation directory to Ubuntu 14.04. In both systems the EUPS commands work, including $EUPS_DIR/bin/eups_setup. The path used for the python interpreter in the master version of EUPS, i.e. /usr/bin/python, does exist in both Ubuntu 14 and CentOS 7.

Please note that I did not test on OS X, but I can confirm that /usr/bin/python also exists on OS X 10.10 (Yosemite) and 10.11 (El Capitan).

[timj]

I don't understand how using EUPS master helped because the Python path is still burned in to the scripts. How come EUPS_PYTHON is now set to /usr/bin/python rather than /bin/python? If you are building with newinstall.sh you can set $PYTHON to be the python version you want to use for EUPS (or use the -p option). This should work if you are using EUPS 2.0.2 or master.

[airnandez]

The test I made did not involve newinstall.sh. This is what I did:

• Clone the EUPS repo
• Build it on CentOS 7. The resulting $EUPS_DIR/bin/eups_setup file uses /usr/bin/python.
• Make a tarball, copy it to a host running Ubuntu and execute various EUPS commands, including source $EUPS_DIR/bin/setups.sh.

The procedure I follow for building the stack v12.0.rc1 is basically:

curl -OL https://sw.lsstcorp.org/eupspkg/newinstall.sh
bash newinstall.sh 
source loadLSST.bash
eups distrib install -t v12_0_rc1 lsst_apps

It is this process which ended up with this issue about EUPS using /bin/python. I completely forgot that one can specify the path to the Python interpreter to newinstall.sh. Thanks for reminding me about this possibility.

I just checked and since I run newinstall.sh as an unprivileged user with almost no environment, the which python command results in /bin/python, hence this issue.

I just did a quick test running newinstall.sh with a preset $PYTHON and it seems it will work for both CentOS and Ubuntu. Next step for me is to rebuild the whole version and report back.

Thanks for your help so far. It looks promising.

[timj]

newinstall.sh just calls the eups configure script with the --with-python option which you can use natively when you build EUPS.

[mjuric]

Good catch, @timj. Should newinstall be changed to prefer /usr/bin/python in general?

[airnandez]

I confirm that building the stack in the way suggested by @timj, that is, using new install.sh -P /usr/bin/python works on both CentOS and Ubuntu and solves this issue. The version v12.0.rc1 built this way is already online.

There still is another issue on Ubuntu when executing the demo but I will open a separate issue.

Thanks to all of you for your help.