(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
>anyway.
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".
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
