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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
