[Numpy-discussion] Numpy 1.3.0 rc1 OS X Installer

Chris Barker Chris.Barker@noaa....
Mon Mar 30 13:59:18 CDT 2009


David Cournapeau wrote:
> On Tue, Mar 31, 2009 at 2:10 AM, Chris Barker <Chris.Barker@noaa.gov> wrote:
>> I assume you meant NOT the easiest? ;-)
> 
> Actually, no, I meant it :) It has gcc, which is the best supported
> compiler by numpy and scipy, there is almost no problem with g77, and
> the optimized blas/lapack is provided by the OS vendor, meaning on ABI
> issue, weird atlas build errors, etc... It is almost impossible to get
> the build wrong on mac os x once you get the right fortran compiler.

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.

> I am almost certain there are issues in some configurations, in
> particular x86_64.

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.

>>> I will thus build binaries
>>> against python.org binaries (I still have to find a way to guarantee
>>> this in the build script, but that should not be too difficult).
>> Hardcoding the path to python should work:
>>
>> PYTHON=/Library/Frameworks/Python.framework/Versions/2.5/bin/python
> 
> Well, yes, but you can't really control this in the bdist_mpkg
> command.

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.


> Also, my current paver file uses virtualenv to build a
> isolated numpy - that's what breaks the .mpkg, but I like this
> approach for building, so I would like to keep it as much as possible.

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?

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

Both?


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

> There are numerous problems with eggs (or more precisely, with "easy"
> install), which I am just not interested in getting into.

me neither --

> In
> particular, it often breaks the user system - fixing it is easy for
> developers/"power users", but is a PITA for normal users. As long as
> easy_install is broken, I don't want to use it.

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

I'm going to poke into bdist_mpkg a bit right now.

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).

-Chris



More information about the Numpy-discussion mailing list