[Numpy-discussion] Numpy 1.3.0 rc1 OS X Installer

[David Cournapeau]

Chris Barker wrote:
>
> I see -- well that's good news. I've found the Universal library 
> requirements to be a pain sometimes, and it probably would be here if 
> Apple wasn't giving us lapack/blas.
>   

Yes, definitely. I could see a lot of trouble if people had to build a
universal ATLAS :)

>
> Well, neither Apple nor python.org's builds are 64 bit anyway at this 
> point. There is talk of quad (i386,and ppc_64 i86_64) builds the the 
> future, though.
>   

Yes, but that's something that has to should be supported sooner rather
than later.

>
> bdist_mpkg should do "the right thing" if it's run with the right 
> python. So you need to make sure you run:
>
> /Library/Frameworks/Python.framework/Versions/2.5/bin/bdist_mpkg
>
> Rather than whatever one happens to be found on your PATH.
>   

Yes, that's the problem: this cannot work directly if I use virtual env,
since virtual env works by recreating a 'fake' python somewhere else.

> Well, maybe we need to hack bdist_mpkg to support this, we're pretty 
> sure that it is possible.
>
> I want o make sure I understand what you want:
>
> Do you want to be able to build numpy in a virtualenv, and then build a 
> mpkg that will install into the users regular Framework?
>   

Yes  - more exactly, there should be a way to guarantee that if I create
a virtual env from a given python interpreter, I can target a .mpkg to
this python interpreter.

> Do you want to be able to build a mpkg that users can install into the 
> virtualenv of their choice?
>   

No - virtualenv is only an artefact of the build process - users should
not care or even know I use virtualenv. I use virtualenv as a fast,
poor-man's 'python chroot'. This way, I can build and install python in
a directory with minimum interaction with the outside environment.
Installing is necessary to build the doc correctly, and I don't want to
mess my system with setuptools stuff.

> Of course, easy_install can do that, when it works!
>   

Except when it doesn't :)

> We were just talking about some of that last night -- we really need a 
> "easy_uninstall" for instance.
>   

yes - but I think it is very difficult to do right with the current
design of easy_install (I have thought a bit about those issues
recently, and I have started writing something to organize my thought a
bit better - I can keep you posted if you are interested).
> By the way, for the libgfortran issue, while statically linking it may 
> be the best option, it wouldn't be too hard to have the mpkg include and 
> install /usr/local/lib/ligfortran.dylib  (or whatever).
>   

I don't think it is a good idea: it would overwrite existing
libgfortran.dylib, which would cause a lot of issues because libgfortran
and gfortran have to be consistent. I know I would be very pissed if
after installing a software, some unrelated software would be broken or
worse overwritten. That's exactly what bothers me with easy_install.

cheers,

David