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 :
>>> 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 :
> 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 cutoff thebranch it's sittingon).
> 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.
> 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.
> 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 ;-)
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the QSERV-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1
