[lsst-dm-stack-users] adding scipy to DMstack installation

[Heather Kelly]

On Mon, Apr 1, 2013 at 1:44 PM, Mario Juric <mjuric at lsst.org> wrote:

> On 3/29/13 10:20 , Paul Price wrote:
> > On Mar 29, 2013, at 12:31 PM, Heather Kelly wrote:
> >> Anyway..  I noticed that rather than using the python (2.7.3+1) that
> was previously installed with the initial installation..we installed python
> 2.7.2+2
> >
> > eups distrib should be thought of as a cloning mechanism --- you're
> cloning the packages that were installed somewhere else.  So the scipy you
> tried to install was built against python 2.7.3+1 rather than 2.7.2+2 on
> the master system.
> >
> > There are a couple of ways you could get scipy built against python
> 2.7.3+1:
> > 1. Request a new build of scipy be created that builds against python
> 2.7.3+1.  Perhaps the way to do this is file a ticket (component = "distrib
> server")?
> > 2. Force your install to use python 2.7.3+1.  To do this, put the
> following in your ~/.eups/site/manifest.remap file:
> >
> > python 2.7.3+1
> >
>
> Hi Heather,
>         There is a version of scipy that builds against Python 2.7.3+1,
> it's
> just that it hasn't been declared "current" (on our distribution
> server). "current" is an EUPS tag tells EUPS which version to install if
> you don't specify one explicitly. So for now, try installing it using:
>
>         eups distrib install --nolocks scipy 0.10.1+1
>
> (note: you can see all versions that are available with "eups distrib
> list", but unfortunately this won't tell you what their dependency tree
> looks like).
>
> Once you do that, declare it as "current" on your SLAC machines with:
>
>         eups declare --nolocks -t current scipy 0.10.1+1
>
> so that you can set it up with just 'setup scipy' (otherwise you'd need
> to specify the version number each time).
>
> On our end, I'll put in a proposal to make the new scipy current so that
> it "just works" in the future.
>
> Let me know if this worked,
> --
> Mario Juric,
>

Hi Mario,

Yes - that worked!

I actually didn't have a site/manifest.remap associated with the RHEL6-64
installation that we did from source..I had tried introducing one but it
didn't seem to make any difference.  Your recipe worked out much better.

I'm now trying to do a similar thing for our RHEL5-64 installation which
was from the binaries you guys provided back in December...initially doing
the eups distrib install --nolocks scipy failed, since it couldn't find
blas or lapack - I did manage to point at our local installation of those.
 Now it's failing since the link path is likely using the location of the
python used when the binaries were created.  Is there a sensible way to add
scipy in this case?  We don't have gcc44 for RHEL5-64 here so the binary
installation seemed the best bet in this case.

Take care,
Heather
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://listserv.lsstcorp.org/pipermail/dm-users/attachments/20130402/fda8503f/attachment.html>