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