[Distutils] bdist_nsis, bdist_deb, bdist_msi, bdist_inno, bdist_pkgtool, bdist_sdux, bdist_mpkg, etc.

[Bob Ippolito]

On Dec 13, 2005, at 1:42 PM, M.-A. Lemburg wrote:

> Bob Ippolito wrote:
>> On Dec 13, 2005, at 11:13 AM, M.-A. Lemburg wrote:
>>>>>> I'd like to focus attention on these distribution formats
>>>>>> that distutils is missing:
>>>>>>
>>>>>
>>>>> I'd like to another important candidate to the list:
>>>>>
>>>>> bdist_mpkg:
>>>>>    Mac OS X installer format
>>>>>    Part of py2app by Bob Ippolito
>>>>>    http://undefined.org/python/py2app.html#bdist-mpkg- 
>>>>> documentation
>>>>
>>>> bdist_mpkg is actually available on its own now, but I'm not  
>>>> sure adding
>>>> it to distutils is a great idea.  The current version is already  
>>>> moved
>>>> over to setuptools, and I'm pretty close to adding egg support  
>>>> to it.  I
>>>> may even require that the Python bits of the installation  
>>>> package are
>>>> eggs, as that would allow me to remove a bunch of code.  Eggs  
>>>> mostly
>>>> obsolete what bdist_mpkg is for, but it's also used to install  
>>>> things
>>>> like documentation and example code, so I'm not going to drop it
>>>> altogether.
>>>
>>> Looks like now is a good time to add it to distutils then :-)
>>
>> No.  Definitely not.
>> ...
>> In other words, I don't consent to adding bdist_mpkg to Python  
>> until it
>> supports eggs.
>
> Ok, then I'll remove the above candidate from the list.
>
> Anyone else interested in writing a bdist_mpkg command
> that doesn't require setuptools ?

That would be a disservice to the Python community.  Since Apple's  
installation packages don't provide for dependency metadata, conflict  
resolution, etc. it's really just a serialized version of "python  
setup.py install".  It doesn't even support relocation in any  
meaningful way to Python users (e.g. you'd have to make separate  
packages for home vs. root installation).

I have definitely had real-world experience where bdist_mpkg fails  
miserably.  The worst cases are when a module turns into a package,  
or is moved from inside a package to top-level, etc.  The old code is  
still around and gets imported, requiring the user to manually  
obliterate something inside their site-packages.

Moving to eggs is the right solution, taking what bdist_mpkg  
currently does and making it available to everyone is a bad idea.

The workaround for this is to include scripts in the installer  
package (pre-install, upgrade, etc.).  The functionality that needs  
to go into those scripts is already part of setuptools and I'd really  
rather not reinvent any wheels.

The other alternative is to use eggs exclusively and simply put  
together an egg management GUI alternative to the easy_install shell  
script.  The egg management GUI would include an egg with some  
version of setuptools for bootstrapping itself, but could use a newer  
system version if available.

In reality, this is an probably a much better option because Apple's  
installer application does not provide for downloading anything,  
checking for updates, or uninstallation.  The only particularly good  
reason I'm keeping bdist_mpkg around is that it is convenient for  
packages that install non-Python things (documentation, Xcode  
templates, examples).

> Given the good documentation for the format, this shouldn't
> be hard:

Apple has more current and official documentation for the format at  
developer.apple.com.  There is one component that still isn't  
documented though: the format used for the Archive.bom file.  This  
file is a binary bill of materials for the package contents, and must  
be generated with /usr/bin/mkbom (or it needs to be reverse  
engineered).  That means that bdist_mpkg can only be used from the  
Mac OS X platform, even for pure Python packages.  bdist_egg, on the  
other hand, makes much more sense.  The .egg file can be built on any  
platform, and can be installed on any other platform (with working  
scripts!), and can even be relocated.

The license for bdist_mpkg is amenable to copying/inclusion, so you  
could probably go ahead and do it if you really really wanted to and  
I'm not going to sue anyone over it... but I still think it would be  
a bad idea to include it in its current or former state, so you're  
not going to see any maintenance or consent from me if you do include  
it.

A version in distutils proper would also be a pain in my ass, because  
that would trump the third party command name and compel me to rename  
it.

-bob