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

M.-A. Lemburg mal at egenix.com
Wed Dec 14 14:49:14 CET 2005


Bob Ippolito wrote:
> 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 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. 

I don't follow you there. It's the standard Mac OS X installation
format and Mac users are used to installing things that way.

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

The target audience for these installers are users which
use the standard Python installation that comes with
Mac OS X. Later on, we might want to add support for
specifying the target path for installing e.g.
into Zope/Plone or other applications that use custom
extensions.

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

The installer preinstall/upgrade scripts can take care
of this.

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

I think differently, but you know that, so I won't elaborate.

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

You don't change package hierarchies that often and if you
do, you have to be careful not to break backwards compatibility
anyway. This will always require writing extra code and being
extra careful regarding import paths stored in Python pickles
and similar formats.

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

Now who's reinventing wheels here ? ;-)

I'm sure that Apple's installer is going to grow at least
the uninstall option sooner or later. Everything else
can easily be done in the installer hook scripts. Please
remember that you already have Python installed on the
machine, so there are plenty things you can do in these
scripts.

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

No problem with that: you need to test things on the platform
itself anyway (including whether the installer works or not).

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

Whether it makes sense or not should be left for the user
to decide. I don't want to argue over this. Instead, I would
like to give users the choice of using a native and well-known
interface for installing software or some other method.

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

Fair enough.

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

We could use a different command name, e.g. bdist_macosx.

Regards,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Dec 14 2005)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::


More information about the Distutils-SIG mailing list