On 23 May 2000, Thomas Heller said:

The bdist command in the CVS version is broken under windows.

1. It seems the needed directories are not created:

Hmm, that shouldn't be too hard to fix... but I wonder why it's not happening? Arg...

2. This error occurrs only after hacking around the second problem: change_root(), which is not implemented for nt.

Having said this, I cannot really understand the purpose of change_root.

Finally I tried distutils under Linux, and it seems that change_root converts relative into (nearly) absolute pathnames: usr/lib/python1.5/site-packages/distutils/...

This MAY make sense under unix, where python is always(?) installed in the same path, but not under windows!

Python is most certainly *not* always installed in the same place on Unix! The purpose of 'change_root()' is to change (eg.) "/usr/lib/python1.5/site-package/distutils" (where the "install" command would normally install the distutils on a Red Hat system) to "build/bdist.linux2-i586/dumb/usr/lib/python1.5/site-packages/distutils" (where it gets installed to create a "dumb" built distribution -- we cd to "build/bdist.linux2-i586/dumb" and then create a tarball or zip file which is meant to be unpacked from the root directory). Make sense? Hope so -- I'm zonked and have to hit the sack. Damn... another night of just dealing with email, no time to code... Greg -- Greg Ward - just another Python hacker gward@python.net http://starship.python.net/~gward/ No man is an island, but some of us are long peninsulas.

On 30 May 2000, Thomas Heller said:

What would the user do with such an archive when his python-site-packages are to be installed into "/usr/local/lib/python1.5/site-packages" ?

There's a reason these are called "dumb" built distributions. They're dumb! Stupid, moronic, clue-challenged -- call 'em what you will they're *dumb*. However, 'change_root()' is definitely needed to support "bdist_rpm", and may well be useful for other Unix build distributions. In Unix, /usr is always /usr, and /usr/local is always /usr/local -- and yes, Python is not necessarily installed in either one of them. However, prefix is not necessarily always exec-prefix, so if we want to put the whole dumb built distribution in one tarball, either we assume prefix == exec-prefix, or we start at the root. Neither one is good enough, which is why I don't expect dumb build distributions to catch on in a big way.

Converting this into the windows world:

Normally python1.5 is installed into "C:\Program Files\Python". So the bdist-created archive would contain filenames like "C:\Program Files\Python\distutils\..."

On a german windows installation Python would be installed (per default) in "C:\Programme\Python" On the other hand, users would have been able to nstall it into "D:\Work\Python\1.5" or whatever they like.

So to me it seems like a bad idea to create archives containing pathnames relative to the root directory.

Good point. Perhaps bdist_dumb should grow a *little* bit of intelligence, and allow the packager to specify if the archive should be relative to prefix or to the root. Yeah, I like that. Just added it to the to-do list.

Anyway, here is the relevant part of the implementation of change_root on windows: -------------------------------------- elif os.name == 'nt': (root_drive, root_path) = os.path.splitdrive (new_root) (drive, path) = os.path.splitdrive (pathname) if path[0] == '\\': path = path[1:] return os.path.join (new_root, path)

Isn't splitdrive'ing new_root unnecessary here? (Oh wait, you just inherited that from my aborted attempt...) Apart from that, this looks right to me... but I just enumerated 20 distinct cases that 'change_root()' has to handle with MS-DOS pathnames, so you can be sure I'll be testing this one carefully. ;-) [...time passes...] OK, I went ahead and wrote the test script. Good thing too: I found a bug in the Unix case! Here's the output; first, the Unix cases: ok: change_root(baz, foo) == baz/foo ok: change_root(/baz, foo) == /baz/foo ok: change_root(baz, /foo) == baz/foo ok: change_root(/baz, /foo) == /baz/foo and now the DOS/Windows cases: ok: change_root(c:\baz, c:\foo) == c:\baz\foo ok: change_root(\baz, c:\foo) == \baz\foo ok: change_root(c:\baz, \foo) == c:\baz\foo ok: change_root(\baz, \foo) == \baz\foo not ok: change_root(c:\baz, c:foo) != c:\baz\foo (got c:\baz\c:foo) not ok: change_root(\baz, c:foo) != c:\baz\foo (got \baz\c:foo) ok: change_root(c:\baz, foo) == c:\baz\foo ok: change_root(\baz, foo) == \baz\foo ok: change_root(c:baz, c:\foo) == c:baz\foo ok: change_root(baz, c:\foo) == baz\foo ok: change_root(c:baz, \foo) == c:baz\foo ok: change_root(baz, \foo) == baz\foo not ok: change_root(c:baz, c:foo) != c:baz\foo (got c:baz\c:foo) not ok: change_root(baz, c:foo) != baz\foo (got baz\c:foo) ok: change_root(c:baz, foo) == c:baz\foo ok: change_root(baz, foo) == baz\foo ok: change_root(d:\baz, c:\foo) == d:\baz\foo not ok: change_root(d:\baz, c:foo) != d:\baz\foo (got d:\baz\c:foo) ok: change_root(d:baz, c:\foo) == d:baz\foo not ok: change_root(d:baz, c:foo) != d:baz\foo (got d:baz\c:foo) Hmmm, not quite there yet. [...more time passes...] OK, got it. Here's the revised 'change_root()'. Passes all those tests for both POSIX and DOS/Windows paths. Anyone care to contribute a Mac OS version (and tests!)? def change_root (new_root, pathname): """Return 'pathname' with 'new_root' prepended. If 'pathname' is relative, this is equivalent to "os.path.join(new_root,pathname)". Otherwise, it requires making 'pathname' relative and then joining the two, which is tricky on DOS/Windows and Mac OS. """ if os.name == 'posix': if not os.path.isabs (pathname): return os.path.join (new_root, pathname) else: return os.path.join (new_root, pathname[1:]) elif os.name == 'nt': (drive, path) = os.path.splitdrive (pathname) if path[0] == '\\': path = path[1:] return os.path.join (new_root, path) elif os.name == 'mac': raise RuntimeError, "no clue how to do this on Mac OS" else: raise DistutilsPlatformError, \ "nothing known about platform '%s'" % os.name There, I've checked it in. And the test script too!

Another minor nit: distutils\archive_util.py, function make_zipfile: The (nested) function visit should normpath() the generated path names, otherwise the created zipfile contains pathnames like ".\distutils\archive_util.py" (Not nice at least).

OK, thanks -- I've checked in your fix.

Question: Zip-files created under windows contain backslashes as path-separators. Do we have to care about this?

Shouldn't that be done magically by os.path.join()?

PS: As soon as the above problems have been cleared, I will prepare a first release of bdist_wininst.py as discussed before.

Hot dog! Greg -- Greg Ward - nerd gward@python.net http://starship.python.net/~gward/ I don't understand the HUMOUR of the THREE STOOGES!!