[Distutils] Extending distutils with 3rd party build commands?

[Bob Ippolito]

On Oct 20, 2004, at 19:03, M.-A. Lemburg wrote:

> Bob Ippolito wrote:
>> On Oct 20, 2004, at 18:10, M.-A. Lemburg wrote:
>>> Bob Ippolito wrote:
>>>
>>>> I've developed two bdist commands (bdist_pkg and bdist_mpkg) for  
>>>> usage on OS X.  These commands apply to any setup.py that supports  
>>>> an "install" command, similar to bdist_wininst, so it would be nice  
>>>> if every setup.py didn't have to explicitly import something in  
>>>> order to get the commands there.
>>>> I know I can make it work with a pth file that imports bdist_pkg,  
>>>> but that seems a bit costly to do because it will end up importing  
>>>> a bunch of stuff (distutils, mainly).
>>>> Is there another way to do it?
>>>
>>>
>>> Submit them for inclusion in the standard distribution ;-)
>> I will, for 2.5... but there's quite some time between now and then.
>>> Please use a different name for bdist_pkg, though, since pkg is  
>>> already
>>> used for Solaris binary packages (unless, of course, yours works for
>>> Solaris packages as well).
>> Well .pkg is used for Mac OS X binary packages too.  Also, the only  
>> hit on google for bdist_pkg is a comment I made a couple months ago.
>
> We once had a bdist_pkgtool in CVS but had to remove it again
> due to copyright issues. Dito for bdist_sdux:
>
> http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Lib/ 
> distutils/command/Attic/
>
> Looks like bdist_pkg is OK after all :-) It's a long time
> ago I had reviewed those packages.

Well I went ahead and made the change to bdist_mpkg.. I haven't put out  
a release of this code yet, and I'm using subversion, so it wasn't a  
big deal.

>> Anyhow, the most useful command is bdist_mpkg, which builds  
>> metapackages, so I'll call it that and remove the bdist_pkg command  
>> if it makes you happy :)
>
> Perhaps bdist_macpkg would be more appropriate if the format
> is not compatible with the pkgtool output ?!

Mac OS X uses two kinds of bundles[1] for installation purposes:

Packages:
     extension of .pkg - contains an archive of files to be installed  
(plus metadata, bill of materials, optional scripts for  
preflight/upgrade/etc.), after installing a Package, a receipt  
(basically a copy sans the archive) is placed into a centralized  
installation database location (/Library/Receipts)

Metapackages:
     extension of .mpkg - contains references to Packages and  
Metapackages (plus metadata, optional scripts, etc.), these may be  
located anywhere that can be referenced absolutely or relative to the  
Metapackage (including inside the Metapackage - it is just a directory)

Naturally, a good choice for the bdist name would be bdist_pkg or  
bdist_mpkg.  Since creating a bdist_mpkg is more useful (separate  
purelib/platlib/scripts/etc.), I've agreed to rename it to bdist_mpkg.   
I don't like bdist_macpkg or anything of that sort.  I would like to  
keep it in line with one of the two extensions that it uses, like  
bdist_rpm (and future obvious choices like bdist_deb, bdist_msi, etc.  
I'm sure).  It's also convenient that "m" is the first letter in Mac,  
and that I'm pretty sure that no other OS uses "mpkg".

[1] Bundles, in Mac OS X terms, are directories of a certain hierarchy  
that are presented opaquely as a single object to the user from the  
GUI.

-bob