[Numpy-discussion] Numpy 1.3.0 rc1 OS X Installer

Christopher Barker Chris.Barker@noaa....
Tue Mar 31 16:39:09 CDT 2009


David Cournapeau wrote:
> Chris Barker wrote:
>> 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.

It does, but we don't need a binary installer for a python that doesn't 
have a binary installer.

>> Well, maybe we need to hack bdist_mpkg to support this, we're pretty 
>> sure that it is possible.

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

Hmmm -- I don't know virtualenv enough to know what the virtualenv knows 
about how it was created...

However, I'm not sure you need to do what your saying here. I imagine 
this workflow:

set up a virtualenv for, say numpy x.y.rc-z

play around with it, get everything to build, etc. with plain old 
setup.py build, setup.py install, etc.

Once you are happy, run:

/Library/Frameworks/Python.framework/Versions/2.5/bin/bdist_mpkg

(or the 2.6 equivalent, etc)

I THINK you'd get a .mpkg that was all set for the user to install in 
their Framework python. As long as you don't run the installer, you 
won't end up with it in your virtualenv.

Or is this what you've tried and has failed for you?

By the way, if you run bdist_mpkg from a version installed into your 
virtualenv, you will get an installer that will install into your 
virtualenv, whit the path hard coded, so really useless.

> Installing is necessary to build the doc correctly, and I don't want to
> mess my system with setuptools stuff.

ah -- maybe that's the issue then -- darn. Are the docs included in the 
.mpkg? Do they need to be built for that?

> I have started writing something to organize my thought a
> bit better - I can keep you posted if you are interested).

yes, I am.

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

True. In that case we could put the dylib somewhere obscure:

/usr/local/lib/scipy1.6/lib/

or even:

/Library/Frameworks/Python.framework/Versions/2.5/lib/

But using static linking is probably better.


Actually, and I betray my ignorance here, but IIUC:

  - There are a bunch of different scipy extensions that use libgfortran
  - Many of them are built more-or-less separately
  - So each of them would get their own copy of the static libgfortran
  - Just how many separate copies of libgfortran is that?
    - Enough to care?
    - How big is libgfortran?

This is making me think solving the dynamic linking problem makes sense.


Also, would it break anything if the libgfortran installed were properly 
versioned:

  libgfortran.a.b.c

Isn't that the point of versioned libs?

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@noaa.gov


More information about the Numpy-discussion mailing list