[Numpy-discussion] Numpy 1.3.0 rc1 OS X Installer
Tue Mar 31 00:09:53 CDT 2009
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
> bdist_mpkg should do "the right thing" if it's run with the right
> python. So you need to make sure you run:
> 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.
More information about the Numpy-discussion