 |
 |
Hello Mario, Thanks for these details which clarify and bring robustness to the initial solution. For my part, i would prefer solution 2 (which could rely on 3 if "eups show python" was an alias to eups_python), as it make eups more independant from environment. It seems it would better prevents conflicts in case eups installs a new eups version relying on a different python. Do you want me to implement this ? Currently it's a pre-requisite for the new Qserv install procedure to work with virtualenv and eups. Have a nice day, Fabrice On 01/03/2014 08:44 PM, Mario Juric wrote: > On 1/3/14 7:16 , Fabrice Jammes wrote: >> 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. >> > ...[snip of discussion about SYSPYTHON]... > > Fabrice, > OK, I understand now. I think it's a good solution. Here's how I'd > propose you restructure your patch to implement that idea: > > * Rename your @SYSTEM_PYTHON@ macro to @EUPS_PYTHON@ > > * Add an option '--with-python' to configure.ac, which will set a > variable EUPS_PYTHON and make it default to /usr/bin/python when not > given. That way, when the user installs eups they're guaranteed > to pick up the system python, or they're *forced* to be explicit > about which one they want used. > > * Then, use this value to expand your the @EUPS_PYTHON@ macros on > various hash-bang (#!) lines. > > * Also, have EUPS export EUPS_PYTHON environment variable whenever it > is setup. You'll need to modify both the bin/setups.* scripts, and > ups/eups.table.in (add an 'envSet(EUPS_PYTHON, @SYSTEM_PYTHON@)' to > the latter), and expand it as with the makefiles. This allows one to > query which Python is EUPS using. > > The logic behind this is that EUPS will always default to system python > (/usr/bin/python). If the user wants something different, they have to > be _explicit_ about it. And if someone wants to distribute EUPS via eups > (say, using eupspkg scripts), they'd configure it as: > > CONFIGURE_OPTIONS='--prefix=$PREFIX --with-python=$EUPS_PYTHON' > > which would ensure the new EUPS inherits the old EUPS' python. > > What do you (and Robert!) think? > > PS: An alternative to the third bullet is to add a new verb to EUPS, > say, 'eups python' (or, better, 'eups show python'), which would return > the interpreter that EUPS is using (basically, just 'print > sys.executable'). Another alternative is to a new script to bin/ > directory, named (say) 'eups_python': > > cat eups_python > #!@EUPS_PYTHON@ > import sys > print sys.executable > > I don't have a strong opinion which one of these three is best (the > middle one is probably most work). Probably the original one. > > - M. > >> 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. >> > I agree with your solution, but I'm nevertheless uneasy about using > blunt tools (-S) unless there's no other way. As you've found out with > virtualenv, there are good reasons why site-specific imports shouldn't > be disabled. > >> 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 ;-) > Good to hear that! ######################################################################## 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