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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4