Mailman 3 September 2000 - Distutils-SIG

New version of bdist_wininst
by Thomas Heller 12 Sep '00

12 Sep '00

I've checked in a slightly changed bdist_wininst version (already on saturday). Here is the log message: The installer now displays info about version of distutils used to create the distribution and the creation date. Takes care of the extra_path argument to the setup function, installs the modules into <prefix>/extra_path and creates a -pth file (like install_lib does). Thomas Heller

2 1

New code snapshot
by Greg Ward 12 Sep '00

12 Sep '00

Hi all -- I've just put together a new code snapshot. From CHANGES.txt: * added --plat-name option to bdist and bdist_dumb commands * added --python and --fix-python options to bdist_rpm, for better control over which Python interpreter is hard-coded in the .spec file * fixed default installation directories for Mac OS; now all modules and extensions go to <prefix>:Lib:site-packages * fixed the "clean" command so it cleans up the build directory for scripts (build/scripts by default) (Bastian Kleineidam) * more improvements to the bdist_wininst command and the installers it generates: ....... (Thomas Heller) * fix the "sdist" command so it deals better with missing, empty, or broken MANIFEST and MANIFEST.in files Hmm, this list is getting long: time for 0.9.3 already? Thomas, can you provide a 25-words-or-less blurb to put in place of that "....."? It's at the usual place: http://www.python.org/sigs/distutils-sig/download.html -- Greg Ward gward(a)python.net http://starship.python.net/~gward/

1 0

Patch for clean.py to remove build_scripts directory
by Bastian Kleineidam 11 Sep '00

11 Sep '00

In Distutils-0.9.2 the clean command does not remove the build_scripts dir. The patch is fixing this. Bastian --- clean.py Sat Aug 5 03:31:54 2000 +++ /usr/local/src/Distutils-0.9.2/distutils/command/clean.py Mon Sep 11 11:37:02 2000 @@ -20,6 +20,8 @@ "build directory for all modules (default: 'build.build-lib')"), ('build-temp=', 't', "temporary build directory (default: 'build.build-temp')"), + ('build-scripts=', None, + "build directory for scripts (default: 'build.build-scripts')"), ('bdist-base=', None, "temporary directory for built distributions"), ('all', 'a', @@ -30,6 +32,7 @@ self.build_base = None self.build_lib = None self.build_temp = None + self.build_scripts = None self.bdist_base = None self.all = None @@ -37,6 +40,7 @@ self.set_undefined_options('build', ('build_base', 'build_base'), ('build_lib', 'build_lib'), + ('build_scripts', 'build_scripts'), ('build_temp', 'build_temp')) self.set_undefined_options('bdist', ('bdist_base', 'bdist_base')) @@ -50,27 +54,16 @@ self.warn ("'%s' does not exist -- can't clean it" % self.build_temp) - - - if self.all: - # remove the module build directory (unless already gone) - if os.path.exists (self.build_lib): - remove_tree (self.build_lib, self.verbose, self.dry_run) - else: - self.warn ("'%s' does not exist -- can't clean it" % - self.build_lib) - - # remove the temporary directory used for creating built - # distributions (default "build/bdist") -- eg. type of - # built distribution will have its own subdirectory under - # "build/bdist", but they'll be taken care of by - # 'remove_tree()'. - if os.path.exists (self.bdist_base): - remove_tree (self.bdist_base, self.verbose, self.dry_run) - else: - self.warn ("'%s' does not exist -- can't clean it" % - self.bdist_base) + # remove build directories + for directory in (self.build_lib, + self.bdist_base, + self.build_scripts): + if os.path.exists (directory): + remove_tree (directory, self.verbose, self.dry_run) + else: + self.warn ("'%s' does not exist -- can't clean it" % + directory) # just for the heck of it, try to remove the base build directory: # we might have emptied it right now, but if not we don't care

2 1

Rewritten 'get_platform()'
by Greg Ward 11 Sep '00

11 Sep '00

Hi all -- for months I have resisted the urge to turn the 'util.get_platform()' function into a miniaturized version of Marc-André's platform.py or the GNU script that spits out the old familar "os-vendor-hardware" triple. Well, today I succumbed. The idea is to generate a string that does a better job of describing the current platform than sys.platform or os.name. This has (so far) two purposes in the distutils: naming the build directories where platform-specific files (.o, .so, etc.) go, and naming built distributions. IMHO the exact information to include depends on the OS: eg. for Linux, the exact kernel version isn't very relevant, whereas for IRIX the version is crucial but the hardware isn't. Typically, though, OS, OS version, and hardware are all relevant. This information is, AFAIK, always available from the 'uname()' system call, exposed in Python as 'os.uname()'. However, it typically needs a bit of massaging to become something that we all know and recognize: eg. "SunOS 5.x" is really "Solaris 2.x". So, here's my initial crack at a rewritten 'get_platform()'. Currently it only handles POSIX platforms; on Windows and Mac OS it'll just return sys.platform (as it has always done). ------------------------------------------------------------------------ def get_platform (): """Return a string that identifies the current platform. This is used mainly to distinguish platform-specific build directories and platform-specific built distributions. Typically includes the OS name and version and the architecture (as supplied by 'os.uname()'), although the exact information included depends on the OS; eg. for IRIX the architecture isn't particularly important (IRIX only runs on SGI hardware), but for Linux the kernel version isn't particularly important. Examples of returned values: linux-i586 linux-alpha (?) solaris-2.6-sun4u irix-5.3 irix64-6.2 For non-POSIX platforms, currently just returns 'sys.platform'. """ if os.name != "posix": # XXX what about the architecture? NT is Intel or Alpha, # Mac OS is M68k or PPC, etc. return sys.platform # Try to distinguish various flavours of Unix (os, host, release, version, machine) = os.uname() os = string.lower(os) if os[:5] == "linux": # At least on Linux/Intel, 'machine' is the processor -- # i386, etc. # XXX what about Alpha, SPARC, etc? return "%s-%s" % (os, machine) elif os[:5] == "sunos": if release[0] >= "5": # SunOS 5 == Solaris 2 os = "solaris" release = "%d.%s" % (int(release[0]) - 3, release[2:]) # fall through to standard os-release-machine representation elif os[:4] == "irix": # could be "irix64"! return "%s-%s" % (os, release) return "%s-%s-%s" % (os, release, machine) ------------------------------------------------------------------------ There are a heck of a lot of POSIX-ish platforms out there, and I'll be very happy if this function returns something sensible for the following: * Linux on any architecture * {Free,Net,Open}BSD on any architecture * Solaris on SPARC, Intel * IRIX * AIX * HP-UX ...plus of course Windows and Mac OS. Like the rest of the world, I'm a little unclear on just how many versions of Windows there really are. ;-) I suspect we can get away with Win32 vs. Win64, but what about NT on Alpha -- is that relevant? Are there any major Unices that I'm missing here? As long as the os-release-machine triple is sensible, it's OK to leave them out of the switch on OS name up there, but I suspect most will need some special-case tweaking like the three that I'm familar with. And yes, I'm going to go dig up MAL's platform.py and see what it does. My informal rule is that, at least for POSIX-ish platforms, we should rely solely on os.uname(). It remains to be seen how foolishly optimistic that is. ;-) Greg -- Greg Ward gward(a)python.net http://starship.python.net/~gward/ War is Peace; Freedom is Slavery; Ignorance is Knowledge

3 3

Default format for "bdist"
by Greg Ward 11 Sep '00

11 Sep '00

Hi all -- as no doubt many of you are aware, the default behaviour for the "bdist" command is to create a "dumb" built distribution -- a /-relative tarball on Unix, and a prefix-relative ZIP file on Windows. I have at times had vague plans for making the Unix default whatever is sensible on the current platform: an RPM, a Debian package, a Free BSD package, a Solaris package, etc. etc. I propose two changes to this: * make a dumb tarball the permanent and everlasting default for Unix: I don't want to write code that attempts to figure out if the current system is RPM-based or Debian-based or uses some other packaging tool (and I'm not keen on adding Marc-André's über-"grok this platform" module -- it's just too big) * make "wininst" the default format on Windows; I'm not aware of any problems with this spiffy little self-installing ZIP file generator, so why the heck not make it the default? Any opinions? If not, I'll go ahead and make this change and check it in as soon as the Python 2.0b1 code freeze is lifted (err, if it isn't already...) Greg -- Greg Ward gward(a)python.net http://starship.python.net/~gward/ If ignorance is bliss, why aren't there more happy people?

4 4

win32 default installation
by Robin Becker 09 Sep '00

09 Sep '00

Is there any reason why the default directory for .pyds seems to be the base python install dir rather than the DLLs directory underneath it? Normally .lib files would go to say c:\Python\Libs and the corresponding .pyd would go to c:\Python\DLLs I have a pure C extension and it therefore has no natural package home so I would normally put that into DLLs, but it seems to be copied into the base dir. -- Robin Becker

3 5

First steps with distutils...
by M.-A. Lemburg 09 Sep '00

09 Sep '00

Here is a list of things I've found while playing with the 0.9.2 snapshot. I've also posted this to Greg directly, but on second thought I think it might be worthwhile getting some feedback from distutilers as well: * distutils doesn't seem to like diretory names in MANIFEST * the setup.py file itself is not included in the source distribution per default (why not ?) * bdist_wininst wants zlib but the installer has a note that it is not using it anymore * bdist_wininst fails with a setup.py file which does not define long_description * bdist_rpm fails with an error in the rpm command (the source rpm is built, but it fails to build to the binary rpm for some reason -- it says, that it can't find the file ??); do I need some new rpm release for this to work ? * the bdist commands don't compile the .py files into .pyo but this is needed in order to use them with python -O * bdist (the dumb version) defaults to creating a tar.gz archive which is relative to / -- it shouldn't use the usr/local/ prefix to make the installation relocateable (e.g. to install under /usr, /opt, /opt/local, etc.) * how can I define the compiler settings for extension compilation (it defaults to -m486 for RPMs -- -mcpu=pentium would be more appropriate; default for standard bdist seems to be -O2 and no architecture) ? And a general question: how can I define which files are documentation, examples and auxiliary files ? More to come :-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

7 17

bdist_wininst updated in CVS repository
by Thomas Heller 07 Sep '00

07 Sep '00

I just checked in a new version of bdist_wininst. Changes: distutils/command/bdist_wininst.py: - the windows installer is again able to compile after installing the files. Note: The default has changed, the packager has to give --no-target-compile/--no-target-optimize to NOT compile on the target system. (Another note: install_lib's --compile --optimize options have the same semantics to switch off the compilation. Shouldn't the names change?) - All references to specific python versions are gone. - A small bug: raise DistutilsPlatformError ("...") instead of raise DistutilsPlatformError, ("...") - When bdist_wininst creates an installer for one specific python version, this is reflected in the name: Distutils-0.9.2.win32-py15.exe instead of Distutils-0.9.2.win32.exe - bdist_wininst, when run as script, reads the wininst.exe file and rewrites itself. Previously this was done by hand. misc/install.c - All the changes needed for compilation - Deleted a lot of debug/dead code Thomas Heller

4 3

Updated Distutils docs
by Greg Ward 06 Sep '00

06 Sep '00

Hi all -- I've been slowly plugging away at the "Distributing Python Modules" manual over the last couple of days, and just uploaded the results to python.org. See http://www.python.org/sigs/distutils-sig/doc/ Especially the following sections of the "Distributing" manual: http://www.python.org/sigs/distutils-sig/doc/dist/describing-extensions.html http://www.python.org/sigs/distutils-sig/doc/dist/setup-config.html http://www.python.org/sigs/distutils-sig/doc/dist/source-dist.html http://www.python.org/sigs/distutils-sig/doc/dist/built-dist.html The "Installing Python Modules" manual has also been updated from the old copy that was on python.org, but this is mainly typo fixes (for now). Any feedback is welcome! Greg -- Greg Ward gward(a)python.net http://starship.python.net/~gward/

1 0

bdist_debian
by Harry Henry Gebel 05 Sep '00

05 Sep '00

I am switching to Debian on my desktop system, and I was wondering if anybody out there is working on bdist_debian? If not I would like to give it a try. I will still be running Mandrake on the other computers on my network, so I will still be able to work on bdist_rpm as well. -- Harry Henry Gebel, Senior Developer, Landon House SBS ICQ# 76308382 West Dover Hundred, Delaware

4 5