According to Thomas Heller: "... the resulting zip-file
from
'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,
perhaps?), 
but isn't much good for Windows, where Python might be
installed anywhere.  

Logged In: YES 
user_id=11375

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

Options:

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

Logged In: YES 
user_id=149084

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.

Logged In: YES 
user_id=31392

Can you look at this one, Thomas?

Logged In: YES 
user_id=11105

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

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.

Logged In: YES 
user_id=149084

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 )"

Logged In: YES 
user_id=11105

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.

Logged In: YES 
user_id=11375

Why not just remove bdist_dumb, then?

Logged In: YES 
user_id=11105

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.

Logged In: YES 
user_id=7887

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 setup.py 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.

Logged In: YES 
user_id=11105

I don't have a strong opinion any longer. Closing the bug with 
postponed or wont fix is fine with me.

Logged In: YES 
user_id=11375

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?

Logged In: YES 
user_id=7887

Can you please do so?

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

Thank you!

Logged In: YES 
user_id=11375

OK, here's a patch that adds a --from-root Boolean option to bdist_dumb.

Logged In: YES 
user_id=11375

Updated version.

Logged In: YES 
user_id=11375

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/dir_util.py .

Logged In: YES 
user_id=11375

Checked in as rev. 1.23 of bdist_dumb.py and rev 1.12 of
dir_util.py.