 |
 |
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! -- Mario Juric, Data Mgmt. Project Scientist, Large Synoptic Survey Telescope Web : http://research.majuric.org Phone : +1 617 744 9003 ######################################################################## 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