Hello Mario,
Thanks for your answer, it's clearer now.
I agree with you on everything, but I've still got one point to
clarify.
More below :
[log in to unmask]"
type="cite">
It's a reasonable proposal (IMHO), except that one wouldn't want to
hardcode the python path as /usr/bin/python, but autodetect it during
the install of EUPS and use that.
I completely agree with you and i've implemented this minor feature in :
https://github.com/fjammes/eups (cf.
https://github.com/fjammes/eups/commit/ceba62ff1b94acb8a006155dff4f4b1686bca625)
(please note that one "-S" has been accidentally removed in bin/eups,
but it's been corrected in a later commit)
Would you agree with this proposal ?
eups relies on python.
So at the first time eups is installed, it will require a
non-eups-installed python (for example a system python) to be
already here. Let's call this non-eups-installed python version
SYSPYTHON.
A simple, and robust, solution could be to force all "eups-only"
commands, for all eups versions, to always rely on SYSPYTHON.
Futhermore, when eups upgrade itself, it will force the
newly-installed eups version to also rely on SYSPYTHON.
Please note that SYSPYTHON will only be used by a very limited set
of "eups-only" commands ("./bin/eups", "setup", and a few others in
eups/bin directory).
All other invocations of "python", after "setup python" command
is issued, will use environment python (i.e. eups-installed
python). This will also apply inside eups build scripts (and for
their commands like "python setup.py ...", which use environment
python)
Note that this bootstrap problem doesn't apply to rpm or dpkg,
because they are compiled.
More below :
[log in to unmask]"
type="cite">
The slight issue I see is that the following could mess up EUPS:
Say I have an existing install of EUPS, and I decide to distribute
updates to EUPS itself as an EUPS package. That is, when I want a user
to upgrade, I ask them to do the following:
eups distrib install eups v1.2.3
eups declare -c eups v1.2.3
Now, if, at the point of eups distrib install, the user has had a
version of python setup-ed that is also distributed through EUPS (say,
anaconda 1.8.0), eups would hard-code the path to that python.
In the proposed solution, eups can't rely on a eups-installed
anaconda, indeed it has to use SYSPYTHON.
So eups command scripts would contains a hard-coded path to
SYSPYTHON (for example /usr/bin/python, or /opt/bin/python,
/usr/local/bin/python).
This SYSPYTHON would be the same as the one that was present, and
required, before the first eups installation.
Note that SYSPYTHON could be upgraded (of course to a
eups-compatible version), for example by system updates, but not by
eups itself :
Iit seems reasonable that eups can't upgrade a components it depends
on (in order not to cut
off the branch it's sitting on).
[log in to unmask]"
type="cite">
Then,
when the user upgrades to a different python, by, say:
eups distrib install anaconda 1.9.0
eups declare -c anaconda 1.9.0
and removes the old version:
eups remove anaconda 1.8.0
their EUPS will stop working (and they won't be warned at all that their
EUPS implicitly depends on anaconda 1.8.0).
In the proposed solution, this command would never have any effect
on any eups versions as it wouldn't impact SYSPYTHON (whose path is
hard-coded in eups scripts).
So eups would continue working.
I think this lead to more robustness for eups as it will become
totally independant from the python versions it installs/manages.
For example, it would allow eups to install/manage softwares relying
on python3, whereas eups would still run with python2 (here you can
also reverse 3 and 2, for the future)
eups could also install/manage non-standard or patched python
implementations.
[log in to unmask]"
type="cite">
This is not a made-up example; distributing Eups through Eups is
legal and possible.
I completely agree with this, it's an interesting feature.
[log in to unmask]"
type="cite">
Thinking more about it, it's really the '-S' on python command line that
is the culprit here. Serge has reported that w/o it, Python succesfully
imports traceback even within the virtualenv. Robert, do you recall the
reason why -S needs to be there?
Removing "-S" is an other solution which works well in this precise
case (i.e. virtualenv/eups), but I think the first one is more
general, and may solve more compatibility problems.
Furthermore, for now, I can't see any drawbacks in this solution.
Hope i'm clear, it's difficult to well describe and discuss this
solution by email.
Thanks again for your help,
Fabrice
P.S. : i've merged this minor feature with eupspkg (using last
version of https://github.com/RobertLuptonTheGood/eups),
and then try to launch qserv install procedure prototype. And, good
news, it works successfully ;-)