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