Hi Mario,

Thanks a lots for these very interesting informations.
I'm new on eups so thanks for helping me, i ask some new questions 
between the lines.

On 16/12/2013 20:04, Mario Juric wrote:
> On 12/16/13 1:50 , Fabrice Jammes wrote:
>> Hello Jacek,
>>
> Hi Fabrice,
> 	EUPS should be compatible with everything from Python 2.2 to 2.7, so I
> don't think you need to worry about much about it. I believe most
> distros still don't make /usr/bin/python python 3; when they begin,
> we'll update EUPS to handle it. Also, I don't think it's good policy to
> have 'python' executable be Python 3 -- there are unfortunately many,
> many, libraries that still require 2.x and expect 'python' to be of that
> flavor. If python 3 is needed, I'd recommend calling the binary python3.
Maybe it would be better if eups always run with system python ?
Indeed for now it switch to eups-installed python once command "setup 
python" is performed.
I've done a quick hack to force eups to use system python, it seems to 
work and is attached to this email (cf. system-python.diff).
For now path to system python binary is hard-coded, but a simple regexp 
in eups Makefile could automate this during eups build.
(i wrote this hack on master branch, after commit : 
cd59995b73dfba8c900b923195b4b05f8e390a5e)
>
> 	Regarding its use with virtualenv, EUPS has been designed with
> virtual-env like functionality in mind -- specifically, it manages the
> PYTHON_PATH for you. So using the two together is likely to generate
> conflicts (though it may not be impossible).
Could one eups expert help me by reviewing eups build file for Qserv ?
It's here : https://github.com/fjammes/misc.git, in the directory 
misc/eups/ (please use tag v0.1)
Currently it install nearly all Qserv dependencies, but not Qserv.

In this version, eups install virtualenv, and then use virtualenv to 
install python.
I thinks virtualenv could be completely supported if there was a eups 
command which allow to run scripts in table files (i've checked eups 
code but and don't think it exists now,
but i could try to add this if you are interested).
So "setup python" would run virtualenv "activate" script, and "unsetup 
python" would run virtualenv "deactivate" script.
So for python, and python only, eups would delegate to virtualenv the 
set up of env variables (i.e PATH, and PYTHONPATH for which system 
instance could even be backuped at setup and restored
at unsetup).

One of the main advantage of using virtualenv is that install of python 
libraries via eups is completely transparent : you don't have to manage 
a dedicated PYTHONPATH in eups build scripts of python libraries.
It also isolate eups-installed python and then prevent conflicts between 
system python user libraries and eups-installed python user libraries.

So added complexity during virtualenv integration with eups may 
substract complexity in all eups build files of python libraries. This 
could be worth ? I don't know as we may later discover conflict between 
eups and virtualenv ?
> 	But I think the point with EUPS is that you shouldn't need to use
> virtualenv. Is there something specific that would prevent you from just
> wrapping packages with .build (or, soon, with pkgbuild scripts), and let
> EUPS manage them? (and my apologies in advance if I missed that
> discussion if it already happened -- just point me to it and I'll read up).

Of course, if you prefer, i can set up build script to install each 
Qserv python lib in a dedicated directory and then add it to PYTHONPATH.
Or also install all python libraries in a unique Qserv python lib directory.
Which solution would you recommend ? I think the second one would be 
simpler and easier to implement, but less flexible as running "setup 
python" would enable all previously installed python libs.
Don't you think it can , in some case, generate conflicts with system 
python user libraries ?

Have a nice day,

Fabrice
>
> Cheers,
> -- Mario
>
>> I see at least 3 solutions :
>>
>> 1. re-building python : it's a bit awkward because eups already needs
>> python
>> and this implies python is already installed on the environnement before
>> installing eups.
>> Furthermore, if eups install a python version it is not compatible with,
>> it will nevertheless swith to use
>> it (instead of system python) and then fails.
>>
>> 2. use systemp python : there's example file in HSC build script. The
>> problem with this solution
>> is that the install tool may have to manage conflict between system
>> python libs and eups-installed python libs.
>>
>> 3. use virtualenv : i think it's a good solution, but eups can't do this
>> at the moment.
>>
>> Maybe it would be a good idea to make eups always run with system
>> python, indeed it would solve point 1. and 3.
>> I can test quickly if it work by updating eups source (in peculiar eups
>> executable which invoke python), and them put a ticket so that
>> eups install tools take in account this improvment.
>>
>> If this solution is too complicated, i will then try point 2.
>>
>> Do you think this proposal is reasonable ?
>>
>> Have a nice day,
>>
>> Fabrice
>>
>>
>> On 12/13/2013 06:33 PM, Jacek Becla wrote:
>>> Fabrice
>>>
>>> Why do we want to / have to use virtualenv? Can we not
>>> rely on eups and do all the things that we wanted to
>>> do via virtualenv inside eups?
>>>
>>> Thanks,
>>> Jacek
>>>
>>>
>>>
>>> On 12/13/2013 09:17 AM, Fabrice Jammes wrote:
>>>> For information, a reply from Jim Bosch about eups and virtualenv. It
>>>> seems that mixing this two software may be quite difficult ...
>>>>
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject:     [HSC Forum] "Installing virtualenv with eups"
>>>> Date:     Fri, 13 Dec 2013 17:09:45 -0000
>>>> From:     [log in to unmask]
>>>> Reply-To:     [log in to unmask]
>>>> To:     [log in to unmask]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> jbosch <http://hsca.ipmu.jp:8080/users/11/jbosch/> posted a comment
>>>> <http://hsca.ipmu.jp:8080/question/167/installing-virtualenv-with-eups/?comment=169#comment-169>
>>>>
>>>>
>>>>
>>>> Commented by jbosch:
>>>>
>>>> I think I agree with your statement about what eups' behavior should be,
>>>> but I'm afraid I'm not enough of a eups expert to be able to make that
>>>> change myself (or even understand all its ramifications). I'm somewhat
>>>> concerned about the idea of trying to use virtualenv with eups, though,
>>>> as I think they're likely to conflict in more ways than this. As I
>>>> understand it, both of them want to take control over your environment
>>>> and determine which versions of other packages will be used, and I'm
>>>> concerned that makes them fundamentally incompatible.
>>>>
>>>> In reply to fjammes's question: Installing virtualenv with eups
>>>>
>>>> Hello,
>>>>
>>>> I need to install virtualenv with eups but i run in a tricky problem :
>>>>
>>>> |[eups@clrlsst-dbmaster-vm eups]$ /usr/bin/python -S -c "import
>>>> traceback"
>>>> [eups@clrlsst-dbmaster-vm eups]$
>>>> /opt/lsst/Linux64/python/virtualenv/bin/python -S -c "import traceback"
>>>> Traceback (most recent call last):
>>>>     File "<string>", line 1, in <module>
>>>> ImportError: No module named traceback
>>>> |
>>>>
>>>> So, it seems virtualenv doesn't import all python standard library.
>>>>
>>>> The problems is that after having installed virtualenv, eups use
>>>> opt/lsst/Linux64/python/virtualenv/bin/python and return next error
>>>> message :
>>>>
>>>> |[eups@clrlsst-dbmaster-vm eups]$ eups
>>>> Traceback (most recent call last):
>>>>     File "/opt/lsst/eups/bin/eups_impl.py", line 26, in <module>
>>>>       import eups.cmd
>>>>     File "/opt/lsst/eups/python/eups/__init__.py", line 1, in <module>
>>>>       from exceptions import *
>>>>     File "/opt/lsst/eups/python/eups/exceptions.py", line 5, in <module>
>>>>       import sys, traceback
>>>> ImportError: No module named traceback
>>>> |
>>>>
>>>> So, my build scripts, or setup/unsetup commands doesn't work anymore.
>>>>
>>>> Is there a way to force eups to always use a fixed python version ?
>>>>
>>>> Thanks,
>>>>
>>>> Fabrice
>>>>
>>>> To change freqency and content of these alerts, please visit your user
>>>> profile <http://hsca.ipmu.jp:8080/users/38/fjammes/subscriptions/>.
>>>>
>>>> If you believe that this message was sent in an error, please email
>>>> about it the forum administrator at [log in to unmask]
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> Sincerely,
>>>> Administrator
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> 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
>>>>
>>> ########################################################################
>>> 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
>> ########################################################################
>> 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
>


########################################################################
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