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

[Ned Deily]

In article 
,
 Chris Barker - NOAA Federal  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 
> > , 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,
 n...@acm.org

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

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

[Chris Barker - NOAA Federal]

>>> Do you think it would be hard to update bdist_mpkg to support the new
>>> format? It is nice to have a simple, pure python, way to build a.

> I don't know, I haven't looked into that yet (but will likely do so for the 
> python.org installers).  I don't even know if the new format is properly 
> documented, with some luck its a closed binary format that can only be 
> created using Apple's tools.

can those tools be called from a command-line, though? Requiring the
dev tools to be installed to build a binary is not a big limitation.

> I don't care too much about having something like bdist_mpkg because it has 
> only limited usefulness: installer.app has limited features (no uninstall, 
> very limited upgrade features), and it is hard to support virtualenv using 
> installer.app packages.

True -- but it was nice to have something folks were familiar with and
could just point and click on.

Ages agio we had a discussion about having a tool that could be
distributed with MacPython that could be associated with *.egg files
and install eggs properly -- so newbies could just point and click on
an agg. That would be nice, but in the end of the day, you're going to
need to learn a bit about installing packages if you're really going
to use Python anyway.

>> Binary eggs do require setup tools or distribute, though that's not
>> too heavy a lift.
>
> IIRC bdist_mpkg also uses setuptools, so that's not really a disadvantage 
> here.

I meant you need setuptool sor distribute to install binary eggs --
requirements for building installers are a non-issue.

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

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.

-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.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

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

[Chris Barker - NOAA Federal]

Oops hit send by accident .


On Dec 17, 2012, at 9:57 AM, Chris Barker - NOAA Federal
 wrote:

> On Dec 17, 2012, at 1:34 AM, Ronald Oussoren  wrote:
>
>>>
>>
>> You could port bdist_mpkg yourself, doing that should be too hard. That 
>> said, bdist_mpkg creates an old package format that doesn't support some of 
>> the more recent features of Installer.app (such as signed packages).
>>
>> Another alternative is to use the packaging tools provided with Xcode, you 
>> will have to do more manually but will end up with a "modern" package format.
>
> Do you think it would be hard to update bdist_mpkg to support the new
> format? It is nice to have a simple, pure python, way to build a.

Binary installer.

>
>> binary eggs and those don't require additional tools.

Binary eggs do require setup tools or distribute, though that's not
too heavy a lift.

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.

Chris



>> Ronald
>>
>>>
>>> -- Russell
>>>
>>> ___
>>> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
>>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
>>
>> ___
>> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

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

[Ronald Oussoren]

On 17 Dec, 2012, at 19:03, Chris Barker - NOAA Federal  
wrote:

> Oops hit send by accident .
> 
> 
> On Dec 17, 2012, at 9:57 AM, Chris Barker - NOAA Federal
>  wrote:
> 
>> On Dec 17, 2012, at 1:34 AM, Ronald Oussoren  wrote:
>> 
 
>>> 
>>> You could port bdist_mpkg yourself, doing that should be too hard. That 
>>> said, bdist_mpkg creates an old package format that doesn't support some of 
>>> the more recent features of Installer.app (such as signed packages).
>>> 
>>> Another alternative is to use the packaging tools provided with Xcode, you 
>>> will have to do more manually but will end up with a "modern" package 
>>> format.
>> 
>> Do you think it would be hard to update bdist_mpkg to support the new
>> format? It is nice to have a simple, pure python, way to build a.
> 
> Binary installer.

I don't know, I haven't looked into that yet (but will likely do so for the 
python.org installers).  I don't even know if the new format is properly 
documented, with some luck its a closed binary format that can only be created 
using Apple's tools.

I don't care too much about having something like bdist_mpkg because it has 
only limited usefulness: installer.app has limited features (no uninstall, very 
limited upgrade features), and it is hard to support virtualenv using 
installer.app packages.

> 
>> 
>>> binary eggs and those don't require additional tools.
> 
> Binary eggs do require setup tools or distribute, though that's not
> too heavy a lift.

IIRC bdist_mpkg also uses setuptools, so that's not really a disadvantage here. 
 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. There is 
some discussion about a new format (see 
, but I'm not sure why that would be 
better than eggs (other than that it isn't a setuptools egg).

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

Ronald

> 
> Chris
> 
> 
> 
>>> Ronald
>>> 
 
 -- Russell
 
 ___
 Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
 http://mail.python.org/mailman/listinfo/pythonmac-sig
 unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
>>> 
>>> ___
>>> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
>>> http://mail.python.org/mailman/listinfo/pythonmac-sig
>>> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

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

[Ronald Oussoren]

On 14 Dec, 2012, at 20:37, Russell E. Owen  wrote:

> Does anyone know of a version of bdist_mpkg that works with Python 3?

I don't know of a py3k port of bdist_mpkg.

> 
> If not, how might one create a Mac binary installer for Python 3?

You could port bdist_mpkg yourself, doing that should be too hard. That said, 
bdist_mpkg creates an old package format that doesn't support some of the more 
recent features of Installer.app (such as signed packages).   

Another alternative is to use the packaging tools provided with Xcode, you will 
have to do more manually but will end up with a "modern" package format.

What are you trying to accomplish? Depending on your usecase you might be able 
to get away with providing binary eggs and those don't require additional tools.

Ronald

> 
> -- Russell
> 
> ___
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG