Hello K.T.,
Excuse me, i made a mistake in my previous email subject, this one
is identical but with the correct subject.
First of all, i wish to all the team a Merry Christmas and a Happy
new year.
Even if its documentation could be improved, eups is a good tool,
it's code is clear and i think it will made qserv build process
more modular, cross-platform, and maintainable.
Futhermore, it seems eups will easilly allow to upgrade Qserv
dependencies durign Qserv development process.
Thanks for your help on this topic, it is very usefull. Thanks
also to other eups pundits (i.e. Mario, Robert and Paul) for their
support. It was a necessary condition to do the job.
Nevertheless, i still need some help on some small details, in
order to
converge towards the right direction.
1. At the moment, the build procedure relies on HSC build
style (like it is what was recommended by Paul Price one month
ago, cf.
http://hsca.ipmu.jp:8080/question/128/more-information-about-eups-create-distrib/)
It builds and installs nearly all Qserv source dependencies (but
not scisql and Qserv itself) on both Ubuntu 13.04 and SL6.2.
For information, i did not use nor lssteups or sconsutils (i only
have the qserv package to build with scons, and Qserv only links
with protobuf, xrootd and mysql).
- Do you confirm i have to move all these build script to pkgbuild
right now ? Is pkgbuild stable enough ? If yes, does
https://github.com/RobertLuptonTheGood/eups.git
master branch support pkgbuild, or shall i use
an other branch ?
- Do you think Qserv build should relies on sconsutils ?
- Do you thinks sconsutils may be compatible with rpm format ?
- Do you confirm Qserv build musn't rely on lssteups (I didn't
notice the use of this tool while i investigated HSC build
scripts.) ?
For the next three points, i answer you between the lines below :
On 12/20/2013 07:55 PM, Kian-Tat Lim wrote:
[log in to unmask]"
type="cite">
Fabrice,
Maybe it would be better if eups always run with system python ?
In the not-too-distant future (maybe even in January or
February), I think we want to convert the LSST Stack to run with the
system Python in all cases, including eups.
Indeed for now it switch to eups-installed python once command
"setup python" is performed.
"setup python" would go away. But I'm not sure what the problem
is with switching Pythons.
[log in to unmask]"
type="cite">
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).
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.
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.
We already have the PYTHONPATH manipulation in the rest of the
LSST Stack, so I think it's best for now to continue with that. In the
longer run, I would like to see all LSST Stack Python modules installed
into a single directory, almost certainly an LSST-specific one and not
the system site-packages -- but they would be swapped in and out on
setup of the individual packages through the use of symbolic links.