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

Phillip J. Eby pje at telecommunity.com
Wed Dec 14 22:59:25 CET 2005

(Disclaimer: this email does not advocate using eggs; it's a comment on 
needed functionality in bdist_mpkg, however it gets implemented.)

At 02:49 PM 12/14/2005 +0100, M.-A. Lemburg wrote:
> > 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.

Only if the upgrade script knows what files are installed; this is much 
easier to handle with an .egg, since PEP 262 was never added to the distutils.

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

Until/unless Apple adds uninstallation support, you'll need to duplicate 
egg functionality in some other way to support this.  If you implement a 
bdist_mpkg that *doesn't* duplicate at least some egg functionality, then 
Bob is correct: it's a *very* bad idea.

>You don't change package hierarchies that often and if you
>do, you have to be careful not to break backwards compatibility

Your argument here appears to be, "things are hard the way we do them now, 
but that's okay because we experts know they're hard and if you're not an 
expert you don't deserve to have things work.  There's no need to do things 
more easily because we already know how to do them the hard way."  I'm not 
sure how that approach helps the distutils "move forward" in any way.

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

Actually, setuptools-based commands trump non-setuptools commands, as long 
as the project uses setuptools.  If it doesn't use setuptools, you can 
force it to by using:

     python -c "import setuptools;execfile('setup.py')" ...

in place of:

     python setup.py ...

So I don't think adding a bdist_mpkg to distutils would actually result in 
any chapping of Bob's posterior.  :)

But I do think that anybody building a bdist_mpkg needs to have it support 
uninstallation (e.g. by creating an uninstall script) and upgrading (by 
finding any previous version and running its uninstall script).  Otherwise, 
there is no reason (that I understand, anyway) to *have* a bdist_mpkg 
format; it won't be doing anything you can't do with say, bdist_dumb or a 
plain "setup.py install".

More information about the Distutils-SIG mailing list