Mailman 3 February 2001 - Distutils-SIG

Beta-release of installers for mx Extensions
by M.-A. Lemburg 16 Feb '01

16 Feb '01

Hi everybody, I am looking for some beta-testers of my new distutils based mx packages, the eGenix mx-Extensions. The extensions themselves are known to compile and run on practically all Python-supported platforms, but the new distutils based installation and build scheme is likely to cause some troubles which I want to move out of the way before going public. I have tested these installers on Linux and Windows without any problems, but would be interested in getting hearing about any problems they might have on the other standard Unix platforms such as AIX, HP-UX, Solaris, etc. and the more exotic ones such as MacOSX and BeOS. You can download the current snapshots from the following URLs. These RPMs are for Linux and i386 machines: http://www.lemburg.com/python/egenix-mx-base-1.0.0-1.i386.rpm http://www.lemburg.com/python/egenix-mx-base-1.0.0-1.src.rpm This archive uses the new bdist_wininst which Thomas Heller has been working on for a few weeks now: http://www.lemburg.com/python/egenix-mx-base-1.0.0.win32-py2.0.exe This archive contains the distutils based installer: http://www.lemburg.com/python/egenix-mx-base-1.0.0.zip Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

1 0

Re: [Distutils] setup.py clean questions
by Jeremy Hylton 16 Feb '01

16 Feb '01

>>>>> "TH" == Thomas Heller <thomas.heller(a)ion-tof.com> writes: >> A meta-question, of course, is what the current status of >> documentation is. I can't find any mention of the clean command >> in the documentation on python.org. Is anyone currently working >> on these? >> TH> Not currently. The situation is desperate. We're all waiting TH> for Greg. TH> There are a lot of other commands not documented at all, only TH> the online help 'setup.py install_data --help'. TH> Even worse: Several options to the setup function are not TH> mentioned anywhere. TH> Although I'm not the right person to write docs (not beeing a TH> native english speaker), and I don't have any qualities as TH> author, I don't have any Latex experience, I'm in the process of TH> convincing me to at least write _some_ docs for some of these. Is there anything I can do to help convince you? I do not follow this list closely and only understand how to do very simple things with distutils. I've been waiting for documentation to learn the rest. I'm sure there are lots of people who can help with markup and copy editing, but fewer who can describe what the code actually does. Jeremy

6 6

Re: deinstall (Was: Re: [Distutils] setup.py clean questions )
by Jack Jansen 16 Feb '01

16 Feb '01

> > But doesn't distutils internally use Unix file name conventions ? > distutils does, but glob doesn't. > I think this was what Jack means. Indeed. And, moreover, when I asked Greg whether the filenames used internally by distutils were unix filenames or URLs he answered that they are URLs. The distinction is minor but important. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: deinstall (Was: Re: [Distutils] setup.py clean questions )
by Jack Jansen 16 Feb '01

16 Feb '01

> You can probably do something like this: > > data_files = [('mx/Doc', glob.glob('mx/Doc/mx*.html'), > ('mx/DateTime/Doc', glob.glob('mx*.html')] > > to install into several subdirectories with the _standard_ > install_data command. NONONONONO, please! Not even more unixisms in distutils! The names you use in your setup script are URLs, not filenames. They look an awful lot like filenames on Unix, but they _are_ URLs. This is important on the Mac, where they're actually converted to the Mac filename convention. Using glob.glob on URLs will prove to be a dissapointing exercise there... Now if we could get some code in distutils that will make people's setup.py script remove itself if they put pathnames like "/usr/local/lib" in there... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 3

Re: deinstall (Was: Re: [Distutils] setup.py clean questions )
by Jack Jansen 16 Feb '01

16 Feb '01

> Here is a simple deinstall command, which you can > use in your setup script. This can at least be a base for > a discussion about a more complete one. Yes, this is pretty much what I had in mind. One point: > elif os.path.isdir(name): > self._removefiles(name, os.path.join(srcdir, n)) > if not self.dry_run: > os.rmdir(name) I think this needs a try/except around the rmdir(), with a message in the except that the rmdir failed, and possibly, if it failed because the directory wasn't empty, a note that there may may be user additions there. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

4 11

Re: [Distutils] setup.py clean questions
by Jack Jansen 16 Feb '01

16 Feb '01

> Good point, but unfortunately difficult to implement since the > clean command gets its parameter from the build command and > you can easily override the names of the various build directories > on the command line or via setup.cfg. > > OTOH, the clean could simply *try* to remove the directory > trees using the default names and produce a warning in case > this fails. We'd then need to expose the temp name generation logic > in the build command, e.g. 'rm -rf temp.<platform>-* lib.<platform>-*' > should do the trick. Alternatively, the clean command could simply > remove the complete build_base tree... Well, Jeremy was asking for a distclean-like facility, so I think that that is the solution. And, while we're at it, I wouldn't mind an uninstall either. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

3 2

setup.py clean questions
by Jeremy Hylton 16 Feb '01

16 Feb '01

I am still a relative novice with the distutils. I used the clean command today and was very confused by how it works. I don't know if my confusion is over the clean command or over the specific setup script. The setup.py was from Andrew's ZODB package. Let me know if my problem is specific to that package. This setup script is used for several packages, including C extensions and straight Python. When I run "python setup.py clean", I get a bunch of warnings, e.g. warning: clean: 'build/temp.linux-i686-2.1' does not exist - can't clean it I don't know what a build/temp.mumble is nor why I should care if it can't be cleaned. If it doesn't exist, it seems that I shouldn't have to be warned that it was cleaned up. Despite all these warnings, nothing has actually been cleaned up. The ExtensionClass build directory, which contains a bunch of .so files, still have all the .so files in it: ~/src/zodb> ls -R ExtensionClass/build/ ExtensionClass/build/: lib.linux-i686-2.1/ ExtensionClass/build/lib.linux-i686-2.1: Acquisition.so* MethodObject.so* MultiMapping.so* Sync.so* ExtensionClass.so* Missing.so* Record.so* ThreadLock.so* In yet another directory, I have some leftover build files from Python 2.0. There doesn't seem to be any way to remove these. A meta-question, of course, is what the current status of documentation is. I can't find any mention of the clean command in the documentation on python.org. Is anyone currently working on these? Late in the process, I decided to read the source and discovered a --all option to clean. That indeed got rid of most of the stuff I was interested in, but spewed even more warnings about directories that didn't exist. It did not, however, remove the 2.0 directories. Jeremy

5 5

Do we need an install_clib command?
by Thomas Heller 09 Feb '01

09 Feb '01

I recently came to think about an install_clib command. The current build_clib builds static libraries, but they can only be used to link them into extensions. Sometimes it may be usefull to have static libraries around. Thomas

2 1

Re: [Distutils] changing default compiler
by Enrico Sirola 08 Feb '01

08 Feb '01

>>>>> "MA" == M -A Lemburg <mal(a)lemburg.com> writes: MA> Enrico Sirola wrote: >> Hello, i wrote a C++ extention module, but distutils keep >> trying to compile it as a plain C interface one. Is t possible >> it's confused by my strange platform name? >> >> from sys import platform print platform >> >> gives out >> >> linux2 >> >> This is prolly non standard, but maybe it's becouse i'm using a >> beta distro (progeny debian)... Anyway everithing works if i >> run compiler commands by hand (changing gcc to g++) and finally >> type "python setup.py install". So, how can i force distutils >> to use g++ instead of gcc? <*slap* self> I was wrong... on standard debian platforms python has the same behavior and everything works fine in distutils. MA> Try the --compiler option to the build_ext command. Note that MA> build_ext is not yet up to compiling C++ code. For gcc a MA> simple renaming of the source file to .cc or .cxx will let gcc MA> compile the file as C++ without any additional options. i just tried, but --compiler let me choose 'unix' only (and then it chooses gcc instead of g++). there's another strange behavior: the directories under build/ have the following names: lib.linux2/ temp.linux2/ and prolly should be lib.linux-i686-1.5/ temp.linux-i686-1.5/ How do distutils select buid-directory names? This could be a good starting point.. Thanks for the help Enrico --

2 1

changing default compiler
by Enrico Sirola 07 Feb '01

07 Feb '01

Hello, i wrote a C++ extention module, but distutils keep trying to compile it as a plain C interface one. Is t possible it's confused by my strange platform name? from sys import platform print platform gives out linux2 This is prolly non standard, but maybe it's becouse i'm using a beta distro (progeny debian)... Anyway everithing works if i run compiler commands by hand (changing gcc to g++) and finally type "python setup.py install". So, how can i force distutils to use g++ instead of gcc? Thanks a lot in advance, Enrico

2 1