EUPS can break itself by setting up a package

[timj]

EUPS believes the PYTHONPATH when it runs its own commands but when packages are set up they can modify PYTHONPATH such that EUPS itself can no longer load. This is particularly evident if you have a Python3 EUPS and you set up a Python 2 stack. The python2 stack will add python_future to the PYTHONPATH such that EUPS will refuse to run.

Should EUPS sanitize $PYTHONPATH?

This was spotted by @jhoblitt in DM-9256.

[timj]

Note, this is true in the LSST case where the stack is using a different python from the one use by EUPS. This can happen with the current newinstall.sh that uses the python from $PATH for EUPS before a stack python is available.

[RobertLuptonTheGood]

I haven't followed the hackery needed to make python3 work (or, more precisely, interoperate with python2).

I don't like sanitising paths, but there is already some special case magic to keep eups running (in particular to handle $EUPS_DIR so that you can use eups to handle eups versions), and this seems somewhat similar. What exactly would we need to do to $PYTHONPATH to handle this?

[timj]

I think it's a general problem for EUPS in that EUPS is written in Python and that a package can be set up that messes with the environment in such a way that EUPS itself can no longer work. I think the fix might be to run the Python binaries with the -E command line option. That will lead to the $PYTHON* environment variables being ignored by python itself on run up. This would require that the EUPS PYTHONPATH (currently in the table file) be moved into eups itself but might be safer.