This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: bdist builds bogus .zips
Type: Stage:
Components: Distutils Versions: Python 2.3
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: akuchling Nosy List: akuchling, jhylton, kbk, niemeyer, theller
Priority: normal Keywords:

Created on 2001-03-22 16:31 by akuchling, last changed 2022-04-10 16:03 by admin. This issue is now closed.

File name Uploaded Description Edit
bdist_dumb.patch akuchling, 2002-11-21 20:38 Updated version that works on Windows and defaults to false.
bdist_dumb.patch akuchling, 2002-11-22 13:49 Use --relative switch
Messages (17)
msg3996 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2001-03-22 16:31
According to Thomas Heller: "... the resulting zip-file
'bdist --formats=zip' is unusable because it contains
filenames relative to
the root directory)"

Such paths may be OK for Unix (cd / and unzip it,
but isn't much good for Windows, where Python might be
installed anywhere.  
msg3997 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2001-05-21 20:39
Logged In: YES 

I expect no one will install from a .zip file on Unix.


1) Make both the .tgz and .zip relative to sys.prefix or 
2) Make only the .zip relative.
3) Document this as being broken and forget about it.

msg3998 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2001-05-27 22:33
Logged In: YES 

gztar, ztar, tar, and zip appear to create the same install tree rooted at / . Only the compression differs. (I guess wininst is the intended way to create a Windows distribution.)

The Unix tree contains PythonX.X in its paths, so not only is the full tree NG for Windows, but if someone prepares a bdist package on a Unix system running 2.2, it appears that it is not going to install correctly on a Unix system running 2.1. It is impractical to ask developers to update their Tools distributions for each version of Python, so what to do?

It may be that the bdist paths should be rooted at site-packages, with script installation to prefix/bin. If there are extensions to go into lib-dynload, the path is ../lib-dynload from site-packages.

Then the user would unpack the file in the site-package directory. Note that right now the file names for source and 'binary' distribution are very similar, but the method of installation is different, and this has to be made clear to the user.

GvR seems to be interested in making the install trees the same on Linux and Windows, that would help.

Incidently, the distutils docs say the default is to install relative to prefix, but it appears that that has not been implemented, the default is / . Also, though the docs mention Windows installers, rpms, etc., they don't say anything about install files prepared with bdist. Maybe no one uses bdist?

If there is something I can do here, let me know. It seems it may take some discussion on python-dev first, though.
msg3999 - (view) Author: Jeremy Hylton (jhylton) (Python triager) Date: 2002-03-01 22:54
Logged In: YES 

Can you look at this one, Thomas?
msg4000 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2002-03-05 21:08
Logged In: YES 

I expect nobody will install from a zip-file on windows, 

I suggest making bdist_wininst the default bdist format on 
windows and forget this one: Everyone should (will?) 
install either from source, or from the native binary 
distribution for his platform.
msg4001 - (view) Author: Kurt B. Kaiser (kbk) * (Python committer) Date: 2002-03-06 20:33
Logged In: YES 

I'm not sure what is meant by "everyone should install from
source or the native binary for his platform."  My
understanding is that Distutils was created to provide a
uniform way to install third party packages.

It seems that bdist_dumb has problems building a package
distribution which will install properly.  What about
non-Linux or Windows systems? It rather looks like the code
is unfinished....

To quote the TODO (DISTUTILS 1.1 PLANS):

"* bdist_dumb should grow a little intelligence: let
packager choose 
whether to make archive relative to prefix or the root
(prefix is essential for proper Windows support )"
msg4002 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2002-03-26 14:07
Logged In: YES 

IMO it is impossible to create a dumb binary distribution 
which can be used to install a package - even on the same 
platform for different Python versions. So it seems the 
only possibility is document dumb binary distros as broken.

The DISTUTILS TODO list is mainly just a list of thoughts 
from the previous maintainer, nobody (so far) is caring too 
much about it currently.

Assigning to AMK: Andrew, if you think this is ok, let us 
close this bug.
msg4003 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2002-03-26 14:52
Logged In: YES 

Why not just remove bdist_dumb, then?
msg4004 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2002-03-26 15:29
Logged In: YES 

Yes. We would have to remove everything except 'rpm' 
and 'wininst' from bdist's available formats lists. But it 
seems the right way to do.
msg4005 - (view) Author: Gustavo Niemeyer (niemeyer) * (Python committer) Date: 2002-11-05 20:02
Logged In: YES 

I don't think we should remove that command. It does no harm
being there,  and it already allows one to install in any
directory. For example, the following command allows one to
build a zip file relative to "site-packages/".

python bdist_dumb --format=zip install
--install-lib /site-packages

OTOH, there are some issues here:

- what should be done about script files, which would
usually be included in /usr/bin on a unix system? binaries
can be moved as well, using the same mechanism explained
above, but currently there's no standard place to but them;
- a binary distribution could include machine specific binaries;

I think the original author had this issues in mind when
created the bdist_dumb command, and that's why it even
includes the platform name in the generated file.

About not being able to use it in different python major
versions, that's a binary distrubtion. Other binary
distributions, like rpm, behave in the same way. Also,
binary compatibility between major versions is not
guaranteed, AFAIK.

Having in mind these issues, my suggestion is to close that
bug and leave the command as is.
msg4006 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2002-11-05 20:07
Logged In: YES 

I don't have a strong opinion any longer. Closing the bug with 
postponed or wont fix is fine with me.
msg4007 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2002-11-05 20:16
Logged In: YES 

I still lean toward removing it.  What platforms are there where one would install by just unzipping a file?

Linux?  No, everyone uses RPM or DEB.  (Maybe Slackware...)

FreeBSD?  No, there's the ports system.

Windows and Mac?  No, people want installers.

Should we take this discussion to distutils-sig or python-dev, perhaps?

msg4008 - (view) Author: Gustavo Niemeyer (niemeyer) * (Python committer) Date: 2002-11-05 20:21
Logged In: YES 

Can you please do so?

Doing so will allow us to close the issue, taking some
action, or just forgetting it.

Thank you!
msg4009 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2002-11-21 19:36
Logged In: YES 

OK, here's a patch that adds a --from-root Boolean option to bdist_dumb.
msg4010 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2002-11-21 20:38
Logged In: YES 

Updated version.
msg4011 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2002-11-22 13:49
Logged In: YES 

Updated patch again, changing the switch to --relative so now you need
to turn it on to get relative paths.  When checked in, the 
ensure_relative() function should probably go in distutils/ .
msg4012 - (view) Author: A.M. Kuchling (akuchling) * (Python committer) Date: 2002-11-26 17:45
Logged In: YES 

Checked in as rev. 1.23 of and rev 1.12 of
Date User Action Args
2022-04-10 16:03:53adminsetgithub: 34216
2001-03-22 16:31:20akuchlingcreate