[Pythonmac-SIG] bdist_mpkg question: python 3 support?

[Ned Deily]

In article 
<CALGmxELrdvrMnQ0HnQnogu3d-6g3CPsXUsbkp=eN1UufXXF+Gg at mail.gmail.com>,
 Chris Barker - NOAA Federal <chris.barker at noaa.gov> wrote:
> > The real problem with binary eggs is that pip doesn't install them, and pip 
> > seems to be the
> > new hotness w.r.t. package management at the moment.
> 
> Indeed it does -- I hadn't realized it didn't install binary eggs -- I
> guess it's been a while since I've tried that!
> 
> > There is some discussion about a new format (see 
> > <http://www.python.org/dev/peps/pep-0427/>, but I'm not sure why that would 
> > be better than eggs (other than that it isn't a setuptools egg).
> 
> It looks like it has some advantages -- but it's not there now, and
> who knows if it ever will be...
> 
> > The packaging landscape for Python still sucks and that might not change 
> > anytime soon.
> 
> :-(
> 
> >> But setup tools used to get all confused by Universal binaries--has
> >> that been fixed? If not, it still may be easier to fix that than do a
> >> bdist_mpkg update.
> >
> > Setuptools works just fine with universal binaries, and always has.
> 
> it build binaries fine, but easy_install got confused when you tried
> to install them.
> 
> > It does treat 'universal' like any other architecture though, which means 
> > it doesn't understand
> > that a binary egg with x86_64 only will work just fine when you are on a 
> > x86_64 machine
> > with a python framework that supports i386 and x86_64. Whether or not that 
> > is a problem
> > depends on your usecase.
> 
> It would be nice to suport that use-case, though it's ripe for
> confusion for casual users.
> 
> But at least a couple years ago, if you build a binary egg with
> setuptools with a universal Python, you'd get an egg that setuptools
> would get confused trying to install -- I can't remember the details,
> but often when a user tried to install it, easy+install would end up
> downloading the source and trying to build it. IIRC, often it had, in
> fact, successfully installed the binary, so you could kill the process
> and have it work -- but that wasn't the least bit clear to the user.
> 
> I also have a vague recollection that you could fix that problem
> simply be re-naming teh binary but my memory is hazy there.

Yes, that's what Ronald is talking about with regard to architectures.  
The platform architecture is encoded into the file name of the egg.  For 
OS X universal builds, the platform names are things like "fat" (meaning 
the build includes "i386" and "ppc") or "intel" ("i386" 32-bit and 
"x86_65" 64-bit).  IIRC, the problem is that setuptools/Distribute just 
does a simple equality compare of that platform name from the egg to 
that of the running Python at install time when what is needed is a set 
comparison, i.e. something like: is there a non-null intersection 
between the set of archs supported by the binaries in the egg with the 
set of archs supported by the Python interpreter being used for 
installation.  (Today you can force a true comparison by changing the 
name of the binary egg file so that the platform strings match.)

> It seems binary egg installation should be pretty easy, and it doesn't
> look like the pip folks are opposed to the idea, so maybe we could add
> that to pip, if distribute builds them properly anyway.

It's not trivially easy or it probably would have been done before.  
IIRC, Setuptools/Distribute has to do some behind the scenes 
platform-specific tricks to ensure that dynamic loads of the extension 
modules work, certainly for zipped binary eggs.  To a large extent, it's 
the tricks that setuptools uses (this and the manipulation of sys.path)
to support various use cases that has given setuptools/Distribute a bad 
rep.  pip makes some important simplifying assumptions; not supporting 
binary eggs is one of them.

-- 
 Ned Deily,
 nad at acm.org