[Distutils] Re: [Python-Dev] Killing off bdist_dumb

[M.-A. Lemburg]

A.M. Kuchling wrote:
> On Wednesday, November 13, 2002, at 05:24 PM, Guido van Rossum wrote:
> 
>> Why do you want to lose bdist_dumb?
> 
> Bug #410541 is that the .zip archive created by bdist_dumb is useless
> because it contains filenames relative to the root directory.  Because 
> Python can
> be installed anywhere on Windows, the .zip files are therefore useless
> for Windows installation.  They might be usable on Unix platforms, as 
> long as
> you're sure about whether Python is in /usr/ or /usr/local, and if tying 
> it to a
> single version is OK (because the path will be 
> /usr/lib/pythonX.Y/site-packages).

You are forgetting the the power of distutils lies in the ability
to subclass these commands, e.g. I use the following to create
Zope product packages:

class mx_bdist_zope(bdist_dumb):

     """ Build binary Zope product distribution.
     """

     def finalize_options (self):

         # Default to ZIP as format on all platforms
         if self.format is None:
             self.format = 'zip'
         bdist_dumb.finalize_options(self)

     # Hack to reuse bdist_dumb for our purposes; .run() calls
     # reinitialize_command() with 'install' as command.
     def reinitialize_command(self, command, reinit_subcommands=0):

         cmdobj = bdist_dumb.reinitialize_command(self, command,
                                                  reinit_subcommands)
         if command == 'install':
             cmdobj.install_lib = 'lib/python'
             cmdobj.install_data = 'lib/python'
         return cmdobj

> This could be fixed by making it possible to use relative paths, of course,
> so you'd have to unpack the resulting .zip in site-packages, but if no 
> one uses .zip files for this purpose, why bother?

bdist_dumb is useful on other platforms as well. The fact
that it basically zips up a binary installation tree is
very handy when you are targetting non-installer platforms
or when you want to deploy to custom Python installations.

> If bdist_wininst wasn't around, then bdist_dumb would be the only way to 
> install on Windows, and clearly this would have to fixed.  With 
> bdist_wininst,
> I don't know if anyone cares.  On Unix bdist_dumb also doesn't handle 
> scripts, apparently.
> 
> Andrew MacIntyre's use of .zip files on OS/2 may save bdist_dumb, though.
> Andrew, was the use of full paths the problem that kept you from using it?
> 
> The options are:
>   1) leave it as-is, broken and useless.  (The current state; this seems 
> pointless.)
>   2) fix it

I all you want is to have the ability to make the paths
relative, I suggest you add an option for this to the
command.

>   3) rip it out

You can't rip out code that's currently in use without providing
at least some kind of alternative. I also don't see any gain
from such an approach.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/