From brian@sweetapp.com Fri Jan 4 19:30:02 2002 From: brian@sweetapp.com (Brian Quinlan) Date: Fri Jan 4 19:30:02 2002 Subject: [Distutils] Possible Distutils shell processing bug In-Reply-To: <3C2DB0F1.3C373130@lemburg.com> Message-ID: <003901c19580$53ca3d80$445d4540@Dell2> Hi, Is it intended that users must escape their own strings, which are passed to the shell? As an example, if I wanted to define a string for the preprocessor, I would have to do something like this: defines = [('VERSION',r'\"1.2.3\"')] If I hadn't escaped the double quotes then the shell would have removed them*. It took me a good five minutes to figure out this problem and I'm sure that others have hit this gotcha. Cheers, Brian * python -c "import sys; print `sys.argv`" test ['-c', 'test'] python -c "import sys; print `sys.argv`" "test" ['-c', 'test'] python -c "import sys; print `sys.argv`" ""test"" ['-c', 'test'] From brian@sweetapp.com Sat Jan 5 22:41:00 2002 From: brian@sweetapp.com (Brian Quinlan) Date: Sat Jan 5 22:41:00 2002 Subject: [Distutils] Installing required DLLs Message-ID: <000701c19664$1e47ea10$445d4540@Dell2> Hi, I was wondering if there is an easy way to install the DLLs that my extension requires from my setup script? I would like to install them in the same directory as my package i.e. MyPackage\ DLL1.dll DLL2.dll __init__.py blah.pyd I use to just use: data_files = [('MyPackage',data_files)] but that no longer works now that extensions go into site-packages. Cheers, Brian From mal@lemburg.com Sun Jan 6 10:15:00 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun Jan 6 10:15:00 2002 Subject: [Distutils] Installing required DLLs References: <000701c19664$1e47ea10$445d4540@Dell2> Message-ID: <3C386980.2050700@lemburg.com> Brian Quinlan wrote: > Hi, > > I was wondering if there is an easy way to install the DLLs that my > extension requires from my setup script? I would like to install them in > the same directory as my package i.e. > > MyPackage\ > DLL1.dll > DLL2.dll > __init__.py > blah.pyd > > I use to just use: > > data_files = [('MyPackage',data_files)] > > but that no longer works now that extensions go into site-packages. Why doesn't it work anymore ? You DLLs should show up in the same directry as the .pyd file. If not something is broken with the site-packages support. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From brian@sweetapp.com Sun Jan 6 13:11:15 2002 From: brian@sweetapp.com (Brian Quinlan) Date: Sun Jan 6 13:11:15 2002 Subject: [Distutils] Installing required DLLs In-Reply-To: <3C386980.2050700@lemburg.com> Message-ID: <001801c196dd$b02a8540$445d4540@Dell2> M.A.Lemburg wrote: > Why doesn't it work anymore ? You DLLs should show up in the > same directry as the .pyd file. If not something is broken with > the site-packages support. The file locations, after installation, are: C:\Python22\ MyPackage\ DLL1.dll DLL2.dll ... lib\ site-packages\ MyPackage\ __init__.py _MyPackage.pyd It looks like the path used by data_files is still relative to the Python installation directory, not to site-packages. Cheers, Brian From mal@lemburg.com Sun Jan 6 17:12:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Sun Jan 6 17:12:01 2002 Subject: [Distutils] Installing required DLLs References: <001801c196dd$b02a8540$445d4540@Dell2> Message-ID: <3C38CBC4.A06AF4AF@lemburg.com> Brian Quinlan wrote: > > M.A.Lemburg wrote: > > Why doesn't it work anymore ? You DLLs should show up in the > > same directry as the .pyd file. If not something is broken with > > the site-packages support. > > The file locations, after installation, are: > > C:\Python22\ > MyPackage\ > DLL1.dll > DLL2.dll > ... > lib\ > site-packages\ > MyPackage\ > __init__.py > _MyPackage.pyd > > It looks like the path used by data_files is still relative to the > Python installation directory, not to site-packages. install_data has never worked for me which is why I created a replacement for the eGenix stuff, but the above looks clearly like a bug. Please post a bug report for this on SF. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Zooko Thu Jan 10 12:05:02 2002 From: Zooko (Zooko) Date: Thu Jan 10 12:05:02 2002 Subject: [Distutils] patch to pybsddb's setup.py for more cmd-line options Message-ID: Folks: Here is appended a patch against pybsddb's setup.py so that you can pass in cmd-line options such as "--extra_link_args=-nodefaultlibs" and they will get passed to distutils's `setup()' function. I tried to make it backwards compatible, but I only tested it on Linux, in my particular application. The application is Mojo Nation [1]. The patch is in Mojo Nation cvs, here: [2]. The makefile which applies the patch and then passes some extra cmd-line arguments is here: [3]. (Search in the makefile text for the string "pybsddb".) Regards, Zooko [1] http://mojonation.net/ [2] http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mojonation/extsrc/bsddb3-3.3.0-moreargs.patch?rev=HEAD&content-type=text/vnd.viewcvs-markup [3] http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mojonation/evil/GNUmakefile?rev=HEAD&content-type=text/vnd.viewcvs-markup --- zooko.com Security and Distributed Systems Engineering --- ------- begin appended patch --- setup.py-orig Wed Jan 9 11:30:05 2002 +++ setup.py Wed Jan 9 11:30:54 2002 @@ -2,7 +2,10 @@ #---------------------------------------------------------------------- # Setup script for the bsddb3 package -import sys, os, string, glob, re +# hacked by Zooko to accept cmdline args and use them. For details see: +# http://mail.python.org/pipermail/distutils-sig/2001-October/002626.html + +import sys, os, string, glob, re, getopt from distutils.core import setup, Extension from distutils.dep_util import newer @@ -12,33 +15,91 @@ debug = '--debug' in sys.argv or '-g' in sys.argv -lflags_arg = [] +global include_dirs, library_dirs, libraries, define_macros, extra_compile_args, extra_link_args, extra_objects + +include_dirs = [] +library_dirs = [] +libraries = [] +define_macros = [] +extra_compile_args = [] +extra_link_args = [] +extra_objects = [] + +def snarf_opts(): + global include_dirs, library_dirs, libraries, define_macros, extra_compile_args, extra_link_args, extra_objects + def usage(le): + print "Hey -- this setup.py script accepts opts like this: getopt.getopt(sys.argv[1:], \"l:a:\", [\"libraries=\", \"extra_link_args=\"]); libraries and args are space-separated (but need to be passed in as one bash word, i.e. the entire space separated list of libraries e.g. --libraries=\"foo bar spam\")" + print "got error: %s: %s" % (le.__class__, `le.args`,) + + # See if there are some special library flags passed in as arguments. + shortopts="l:a:I:c:L:o:" + longopts=['libraries=', 'extra_link_args=', 'include_dirs=', 'extra_compile_args=', 'library_dirs=', 'extra_objects=', 'berkeley-db=', 'lflags=', 'libs=',] + try: + opts, args = getopt.getopt(sys.argv[1:], shortopts, longopts) + except getopt.GetoptError, le: + # print help information and exit: + usage(le) + sys.exit(2) + + # Any options that we don't process get added to `newargv' to be passed on. + newargv = [] + + for o, a in opts: + if o in ('-l', '--libraries',): + libraries.extend(string.split(a)) + elif o in ('-a', '--extra_link_args',): + extra_link_args.extend(string.split(a)) + elif o in ('-I', '--include_dirs',): + include_dirs.extend(string.split(a)) + elif o in ('-c', '--extra_compile_args',): + extra_compile_args.extend(string.split(a)) + elif o in ('-L', '--library_dirs',): + library_dirs.extend(string.split(a)) + elif o in ('-o', '--extra_objects',): + extra_objects.extend(string.split(a)) + + ### begin options defined by `bsddb3-3.3.0/setup.py' before Zooko touched it. Zooko changed the code to parse these with getopt instead of with string.find. + elif o == '--berkeley-db': + global BERKELEYDB_DIR + BERKELEYDB_DIR = a + elif o == '--lflags': + global LFLAGS + LFLAGS = a + elif o == '--libs': + global LIBS + LIBS = a + ### end options defined by `bsddb3-3.3.0/setup.py' before Zooko touched it. Zooko changed the code to parse these with getopt instead of with string.find. + + else: + assert o[0] == '-' + if o[1] == '-': + if a: + newargv.append(o + ' ' + a) + else: + newargv.append(o) + else: + if a: + newargv.append(o+a) + else: + newargv.append(o) + sys.argv[1:] = newargv + sys.argv.extend(args) if os.name == 'posix': # Allow setting the DB dir and additional link flags either in # the environment or on the command line. # First check the environment... + global BERKELEYDB_DIR, LFLAGS, LIBS BERKELEYDB_DIR = os.environ.get('BERKELEYDB_DIR', '') LFLAGS = os.environ.get('LFLAGS', []) LIBS = os.environ.get('LIBS', []) # ...then the command line. - # Handle --berkeley-db=[PATH] and --lflags=[FLAGS] - args = sys.argv[:] - for arg in args: - if string.find(arg, '--berkeley-db=') == 0: - BERKELEYDB_DIR = string.split(arg, '=')[1] - sys.argv.remove(arg) - elif string.find(arg, '--lflags=') == 0: - LFLAGS = string.split(string.split(arg, '=')[1]) - sys.argv.remove(arg) - elif string.find(arg, '--libs=') == 0: - LIBS = string.split(string.split(arg, '=')[1]) - sys.argv.remove(arg) + snarf_opts() if LFLAGS or LIBS: - lflags_arg = LFLAGS + LIBS + extra_links_args.extend((LFLAGS, LIBS,)) # If we were not told where it is, go looking for it. incdir = libdir = None @@ -60,7 +121,6 @@ else: incdir = None - if not BERKELEYDB_DIR and not incdir and not libdir: print "Can't find a local db3 installation." sys.exit(1) @@ -69,9 +129,7 @@ if not incdir: incdir = os.path.join(BERKELEYDB_DIR, 'include') if not libdir: libdir = os.path.join(BERKELEYDB_DIR, 'lib') if not '-ldb' in LIBS: - libname = ['db'] - else: - libname = [] + libraries.append('db') utils = [] @@ -108,6 +166,7 @@ elif os.name == 'nt': + snarf_opts() # The default build of Berkeley DB for windows just leaves # everything in the build dirs in the db source tree. That means @@ -142,9 +201,9 @@ print 'Detected BerkeleyDB version', ver, 'from db.h' if debug: - libname = ['libdb%ssd' % ver] # Debug, static + libraries.append('libdb%ssd' % ver) # Debug, static else: - libname = ['libdb%ss' % ver] # Release, static + libraries.append('libdb%ss' % ver) # Release, static utils = [("bsddb3/utils", ["db/bin/db_archive.exe", "db/bin/db_checkpoint.exe", @@ -168,6 +227,9 @@ open('src/version.h', 'w').write('#define PY_BSDDB_VERSION "%s"\n' % VERSION) +include_dirs.append(incdir) +library_dirs.append(libdir) + # do the actual build, install, whatever... setup(name = 'bsddb3', version = VERSION, @@ -192,10 +254,13 @@ packages = ['bsddb3'], ext_modules = [Extension('bsddb3._db', sources = ['src/_db.c'], - include_dirs = [ incdir ], - library_dirs = [ libdir ], - libraries = libname, - extra_link_args = lflags_arg, + include_dirs = include_dirs, + define_macros = define_macros, + extra_compile_args = extra_compile_args, + extra_link_args = extra_link_args, + extra_objects = extra_objects, + library_dirs = library_dirs, + libraries = libraries, )], data_files = utils, ) From Achim.Gaedke@uni-koeln.de Fri Jan 11 13:02:07 2002 From: Achim.Gaedke@uni-koeln.de (Achim Gaedke) Date: Fri Jan 11 13:02:07 2002 Subject: [Distutils] test suite support Message-ID: <3C3F27F7.7C527979@uni-koeln.de> Hello! I am using distutils that come with python2.2 to build and install the module pygsl (http://pygsl.sourceforge.net). In order to ensure quality I started to collect tests with unittest. In analogy to the automake feature "make test" or "make check" I would like to have a standard test command for setup.py . For test purposes, I have developed this script: ### Begin import sys import os.path import distutils.sysconfig import distutils.util import unittest my_path=os.path.dirname(os.path.abspath(sys.argv[0])) my_version=distutils.sysconfig.get_config_var('VERSION') build_lib_path=os.path.join(my_path,"build","lib.%s-%s"%(distutils.util.get_platform(),my_version)) test_path=os.path.join(my_path,"tests") sys.path.insert(-1,build_lib_path) sys.path.insert(-1,test_path) from histogram_test import * from rng_test import * from const_test import * if __name__ == "__main__": unittest.main() ### End It adds the temporary build directory and the test suite directory to the module search path. After that it imports all test cases and executes them. So I can test my modules without installing it to the site-packages. Maybe similar code could be included in a test command. Could you tell me the correct way to get build_lib_path ? From mwh@python.net Sun Jan 13 09:45:01 2002 From: mwh@python.net (Michael Hudson) Date: Sun Jan 13 09:45:01 2002 Subject: [Distutils] Possible Distutils shell processing bug In-Reply-To: "Brian Quinlan"'s message of "Fri, 4 Jan 2002 16:31:33 -0800" References: <003901c19580$53ca3d80$445d4540@Dell2> Message-ID: <2mhepqb9ae.fsf@starship.python.net> "Brian Quinlan" writes: > Is it intended that users must escape their own strings, which are > passed to the shell? As an example, if I wanted to define a string for > the preprocessor, I would have to do something like this: > > defines = [('VERSION',r'\"1.2.3\"')] > > If I hadn't escaped the double quotes then the shell would have removed > them*. > > It took me a good five minutes to figure out this problem and I'm sure > that others have hit this gotcha. Hmm. What happens in this instance on Windows? We should probably try to make the behaviour consistent. But quoting in sh is a quick way to insanity. Cheers, M. -- I'm not sure that the ability to create routing diagrams similar to pretzels with mad cow disease is actually a marketable skill. -- Steve Levin -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html From brian@sweetapp.com Sun Jan 13 19:40:01 2002 From: brian@sweetapp.com (Brian Quinlan) Date: Sun Jan 13 19:40:01 2002 Subject: [Distutils] Possible Distutils shell processing bug In-Reply-To: <2mhepqb9ae.fsf@starship.python.net> Message-ID: <002c01c19c94$2a11b160$445d4540@Dell2> Michael wrote: > Hmm. What happens in this instance on Windows? We should probably > try to make the behaviour consistent. > > But quoting in sh is a quick way to insanity. cmd.exe and sh do the same thing: they collect quoted arguments into one command argument and remove the quotes. So the solution seems pretty simple: just replace all instances of " with \" Cheers, Brian From mal@lemburg.com Mon Jan 14 05:22:04 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Jan 14 05:22:04 2002 Subject: [Distutils] Possible Distutils shell processing bug References: <002c01c19c94$2a11b160$445d4540@Dell2> Message-ID: <3C42B191.633512AA@lemburg.com> Brian Quinlan wrote: > > Michael wrote: > > Hmm. What happens in this instance on Windows? We should probably > > try to make the behaviour consistent. > > > > But quoting in sh is a quick way to insanity. > > cmd.exe and sh do the same thing: they collect quoted arguments into one > command argument and remove the quotes. So the solution seems pretty > simple: just replace all instances of " with \" I suppose we should add an API for shell quoting to util.py... provided we can come up with a sane standard for quoting. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mwh@python.net Mon Jan 14 06:57:01 2002 From: mwh@python.net (Michael Hudson) Date: Mon Jan 14 06:57:01 2002 Subject: [Distutils] Possible Distutils shell processing bug In-Reply-To: "Brian Quinlan"'s message of "Fri, 4 Jan 2002 16:31:33 -0800" References: <003901c19580$53ca3d80$445d4540@Dell2> Message-ID: <2mr8otuowq.fsf@starship.python.net> "Brian Quinlan" writes: > Hi, > > Is it intended that users must escape their own strings, which are > passed to the shell? As an example, if I wanted to define a string for > the preprocessor, I would have to do something like this: > > defines = [('VERSION',r'\"1.2.3\"')] > > If I hadn't escaped the double quotes then the shell would have removed > them*. Hang on. Are you sure about this? Consider: (sorry for the long lines) [mwh@starship foo]$ cat setup.py from distutils.core import setup, Extension setup(ext_modules=[Extension("foo", ["foomodule.c"], define_macros=[("FOO",'"a"')])]) [mwh@starship foo]$ cat foomodule.c #include static PyObject* foo_func(PyObject* self, PyObject* args) { return PyString_FromString(FOO); } static PyMethodDef foo_meths[] = { { "func", foo_func } }; void initfoo() { Py_InitModule("foo", foo_meths); } [mwh@starship foo]$ python setup.py build_ext running build_ext building 'foo' extension creating build creating build/temp.linux-i686-2.2 gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -DFOO="a" -I/home/crew/mwh/include/python2.2 -c foomodule.c -o build/temp.linux-i686-2.2/foomodule.o foomodule.c:15: warning: function declaration isn't a prototype creating build/lib.linux-i686-2.2 gcc -shared build/temp.linux-i686-2.2/foomodule.o -o build/lib.linux-i686-2.2/foo.so [mwh@starship foo]$ PYTHONPATH=build/lib.linux-i686-2.2 python Python 2.2c1+ (#1, Dec 26 2001, 21:36:30) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import foo >>> foo.func() 'a' >>> What made you think quotes were disappearing? Cheers, M. -- Important data should not be entrusted to Pinstripe, as it may eat it and make loud belching noises. -- from the announcement of the beta of "Pinstripe" aka. Redhat 7.0 From mal@lemburg.com Mon Jan 14 16:34:01 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Jan 14 16:34:01 2002 Subject: [Distutils] test suite support References: <3C3F27F7.7C527979@uni-koeln.de> Message-ID: <3C434F31.D0A714AB@lemburg.com> Achim Gaedke wrote: > > I am using distutils that come with python2.2 to build and install the module > pygsl (http://pygsl.sourceforge.net). In order to ensure quality I started to > collect tests with unittest. > > In analogy to the automake feature "make test" or "make check" I would like to > have a standard test command for setup.py . Why not add this as new "test" command to distutils ?! It could have options which programmers can then set in order for the command to find the test suits to run, e.g. python setup.py test I'd suggest to use an approach similar to what build_ext and the Extension class have to offer (in terms of code design). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From Achim.Gaedke@uni-koeln.de Tue Jan 15 12:03:01 2002 From: Achim.Gaedke@uni-koeln.de (Achim Gaedke) Date: Tue Jan 15 12:03:01 2002 Subject: [Distutils] test suite support References: <3C3F27F7.7C527979@uni-koeln.de> <3C434F31.D0A714AB@lemburg.com> Message-ID: <3C445D78.9055BCAF@uni-koeln.de> "M.-A. Lemburg" schrieb: > > Why not add this as new "test" command to distutils ?! It could have > options which programmers can then set in order for the command to find > the test suits to run, e.g. > > python setup.py test > > I'd suggest to use an approach similar to what build_ext and the > Extension class have to offer (in terms of code design). > I will try to do so next week, but I feel impelled to read a lot of distutils soure. From thomas.heller@ion-tof.com Tue Jan 15 13:48:01 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Tue Jan 15 13:48:01 2002 Subject: [Distutils] test suite support References: <3C3F27F7.7C527979@uni-koeln.de> <3C434F31.D0A714AB@lemburg.com> Message-ID: <02a101c19df5$10a742f0$e000a8c0@thomasnotebook> From: "M.-A. Lemburg" > > Why not add this as new "test" command to distutils ?! It could have > options which programmers can then set in order for the command to find > the test suits to run, e.g. > > python setup.py test > > I'd suggest to use an approach similar to what build_ext and the > Extension class have to offer (in terms of code design). > I've used the following code which was posted by Berthold H=F6llmann to this list with good success in several of my setup scripts... Thomas class test(Command): # Original version of this class posted # by Berthold H=F6llmann to distutils-sig@python.org description =3D "test the distribution prior to install" user_options =3D [ ('test-dir=3D', None, "directory that contains the test definitions"), ('test-prefix=3D', None, "prefix to the testcase filename"), ('test-suffixes=3D', None, "a list of suffixes used to generate names the of the testcases"= ) ] def initialize_options(self): self.build_base =3D 'build' # these are decided only after 'build_base' has its final value # (unless overridden by the user or client) self.test_dir =3D 'tests' self.test_prefix =3D 'test_' self.test_suffixes =3D None # initialize_options() def finalize_options(self): import os if self.test_suffixes is None: self.test_suffixes =3D [] pref_len =3D len(self.test_prefix) for file in os.listdir(self.test_dir): if (file[-3:] =3D=3D ".py" and file[:pref_len]=3D=3Dself.test_prefix): self.test_suffixes.append(file[pref_len:-3]) build =3D self.get_finalized_command('build') self.build_purelib =3D build.build_purelib self.build_platlib =3D build.build_platlib # finalize_options() def run(self): import sys # Invoke the 'build' command to "build" pure Python modules # (ie. copy 'em into the build tree) self.run_command('build') # remember old sys.path to restore it afterwards old_path =3D sys.path[:] # extend sys.path sys.path.insert(0, self.build_purelib) sys.path.insert(0, self.build_platlib) sys.path.insert(0, self.test_dir) # build include path for test for case in self.test_suffixes: TEST =3D __import__(self.test_prefix+case, globals(), locals(), ['']) try: tested_modules =3D TEST.tested_modules except AttributeError: tested_modules =3D None else: from code_coverage import Coverage coverage =3D Coverage(modules=3Dtested_modules) sys.settrace(coverage.trace) TEST.test() if tested_modules is not None: # reload tested modules to get coverage of imports, etc. for name in tested_modules: module =3D sys.modules.get(name) if module: reload(module) sys.settrace(None) sys.stdout.write("code coverage:\n") coverage.write_results(sys.stdout) # restore sys.path sys.path =3D old_path[:] # run() # class test From gustav@morpheus.demon.co.uk Tue Jan 15 17:27:07 2002 From: gustav@morpheus.demon.co.uk (Paul Moore) Date: Tue Jan 15 17:27:07 2002 Subject: [Distutils] test suite support In-Reply-To: <02a101c19df5$10a742f0$e000a8c0@thomasnotebook> References: <3C3F27F7.7C527979@uni-koeln.de> <3C434F31.D0A714AB@lemburg.com> <02a101c19df5$10a742f0$e000a8c0@thomasnotebook> Message-ID: On Tue, 15 Jan 2002 19:46:41 +0100, "Thomas Heller" wrote: >From: "M.-A. Lemburg" >> >> Why not add this as new "test" command to distutils ?! It could have >> options which programmers can then set in order for the command to = find >> the test suits to run, e.g. >> >> python setup.py test >> >> I'd suggest to use an approach similar to what build_ext and the >> Extension class have to offer (in terms of code design). >> >I've used the following code which was posted by Berthold H=F6llmann >to this list with good success in several of my setup scripts... [...] I strongly support *any* form of a test command. I think that this is very important, to encourage people to provide test suites with their distributions. The problem, to some extent, is that there are too many "home-grown" solutions. We just need one version, added to the "official" distribution. Can Thomas' version be added to CVS, so that it gets into Python 2.3? It's a real shame, in retrospect, that this didn't get done for 2.2. If not Thomas' version, then can someone provide a version? But this is very definitely a case where anything is better than nothing... Paul. (Sorry, I campaigned about this a long while ago, but I let it drop. I shouldn't have.) From Achim.Gaedke@uni-koeln.de Tue Jan 15 18:01:01 2002 From: Achim.Gaedke@uni-koeln.de (Achim Gaedke) Date: Tue Jan 15 18:01:01 2002 Subject: [Distutils] test suite support References: <3C3F27F7.7C527979@uni-koeln.de> <3C434F31.D0A714AB@lemburg.com> <02a101c19df5$10a742f0$e000a8c0@thomasnotebook> Message-ID: <3C44B3FE.FA99688@uni-koeln.de> I'd like to have unittest support, because it seems to me comfortable to = unify testsuites and easy to adapt own existing tests, but I have not enough experience to write good code for this purpose. I suggest two changes to Thomas code: * Use unittest.main(module) for test execution and * prepend the build-directory used by build and build_ext to sys.path, so= the new modules are found. That is important for c-code. Some links for unittest: Homepage: http://pyunit.sourceforge.net/ Python Docs: http://www.python.org/doc/current/lib/module-unittest.html Paul Moore schrieb: >=20 > On Tue, 15 Jan 2002 19:46:41 +0100, "Thomas Heller" > wrote: >=20 > >From: "M.-A. Lemburg" > >> > >> Why not add this as new "test" command to distutils ?! It could have > >> options which programmers can then set in order for the command to f= ind > >> the test suits to run, e.g. > >> > >> python setup.py test > >> > >> I'd suggest to use an approach similar to what build_ext and the > >> Extension class have to offer (in terms of code design). > >> > >I've used the following code which was posted by Berthold H=F6llmann > >to this list with good success in several of my setup scripts... > [...] >=20 > I strongly support *any* form of a test command. I think that this is > very important, to encourage people to provide test suites with their > distributions. >=20 > The problem, to some extent, is that there are too many "home-grown" > solutions. We just need one version, added to the "official" > distribution. >=20 > Can Thomas' version be added to CVS, so that it gets into Python 2.3? > It's a real shame, in retrospect, that this didn't get done for 2.2. If > not Thomas' version, then can someone provide a version? But this is > very definitely a case where anything is better than nothing... >=20 > Paul. >=20 > (Sorry, I campaigned about this a long while ago, but I let it drop. I > shouldn't have.) >=20 > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig From thomas.heller@ion-tof.com Wed Jan 16 05:39:00 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Wed Jan 16 05:39:00 2002 Subject: [Distutils] test suite support References: <3C3F27F7.7C527979@uni-koeln.de> <3C434F31.D0A714AB@lemburg.com> <02a101c19df5$10a742f0$e000a8c0@thomasnotebook> <3C44B3FE.FA99688@uni-koeln.de> Message-ID: <076c01c19e79$d863b8d0$e000a8c0@thomasnotebook> From: "Achim Gaedke" > I'd like to have unittest support, because it seems to me comfortable to unify > testsuites and easy to adapt own existing tests, but I have not enough > experience to write good code for this purpose. > > I suggest two changes to Thomas code: > > * Use unittest.main(module) for test execution and I know about unittest, but don't use it any more. I've converted all my tests to Tim Peters' doctest. The test command I posted simply calls a test function, which can use doctest, unittest or whatever internally. > * prepend the build-directory used by build and build_ext to sys.path, so the > new modules are found. That is important for c-code. Thats what these lines are supposed to do: # extend sys.path sys.path.insert(0, self.build_purelib) sys.path.insert(0, self.build_platlib) Thomas From Paul.Moore@atosorigin.com Wed Jan 16 08:53:01 2002 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Wed Jan 16 08:53:01 2002 Subject: [Distutils] test suite support Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5B17A@UKRUX002.rundc.uk.origin-it.com> From: Achim Gaedke [mailto:Achim.Gaedke@uni-koeln.de] > I'd like to have unittest support, because it seems to me > comfortable to unify > testsuites and easy to adapt own existing tests, but I have not enough > experience to write good code for this purpose. > > I suggest two changes to Thomas code: I have no particular view on these two changes. But I would definitely rather see them as change requests to the released distutils test support, instead of discussion items before anything is added. In other words, just because we have something in place, doesn't mean we can't change it later if needed. But we should get something in, sooner rather than later. Just my 2p worth, Paul. From thomas.heller@ion-tof.com Wed Jan 16 09:17:27 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Wed Jan 16 09:17:27 2002 Subject: [Distutils] test suite support References: <714DFA46B9BBD0119CD000805FC1F53B01B5B17A@UKRUX002.rundc.uk.origin-it.com> Message-ID: <0a7101c19e98$5b7ab2f0$e000a8c0@thomasnotebook> From: "Moore, Paul" > I have no particular view on these two changes. But I would definitely > rather see them as change requests to the released distutils test support, > instead of discussion items before anything is added. In other words, just > because we have something in place, doesn't mean we can't change it later if > needed. But we should get something in, sooner rather than later. You fear endless discussions resulting in no released code? Now that distutils doesn't have a named maintainer, how are we supposed to proceed? Anyone writes a PEP, or is this overkill? Anyway, lets try to clear this *fast*. Thomas From Paul.Moore@atosorigin.com Wed Jan 16 09:50:00 2002 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Wed Jan 16 09:50:00 2002 Subject: [Distutils] test suite support Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5B17C@UKRUX002.rundc.uk.origin-it.com> From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > You fear endless discussions resulting in no released code? Exactly. Happens too often for my liking... > Now that distutils doesn't have a named maintainer, > how are we supposed to proceed? Anyone writes a PEP, or > is this overkill? I'd suggest that a PEP is overkill. I see PEPs as more related to Python language changes, rather than library issues (unless the library issue is far-reaching or fundamental). I'd suggest a proposal to distutils-sig (basically, just a repost of your message with the suggested code in it), with a suggested discussion period of (say) 1 week. If no-one raises a showstopper objection in that time, check it in. Any discussion over the exact details of features should be noted but treated as requests for changes which can be submitted as patches *after* the release (unless they are small and non-controversial, when they can just be done). Actually, I'd just check it in and wait for comments, but I like to live dangerously... :-) > Anyway, lets try to clear this *fast*. Yes. Treating your suggested code as a proposal, I've a couple of comments. None to be treated as showstoppers - count me as +1 on checking this in regardless - but possibly worth consideration: 1. What happens if there are no tests? Rather than silently doing nothing, I'd suggest printing "No tests defined", to act as a reminder that tests would be nice... 2. What is the code_coverage module? It's not standard, so I guess it should not be included in a standard distutils command. Although including code coverage reports in test results is nice, so using it if it is available, and skipping the coverage tests if not, might be good. Paul. From thomas.heller@ion-tof.com Wed Jan 16 10:18:01 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Wed Jan 16 10:18:01 2002 Subject: [Distutils] test suite support References: <714DFA46B9BBD0119CD000805FC1F53B01B5B17C@UKRUX002.rundc.uk.origin-it.com> Message-ID: <0b2101c19ea0$d605e0f0$e000a8c0@thomasnotebook> From: "Moore, Paul" > From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > > You fear endless discussions resulting in no released code? > > Exactly. Happens too often for my liking... > > > Now that distutils doesn't have a named maintainer, > > how are we supposed to proceed? Anyone writes a PEP, or > > is this overkill? > > I'd suggest that a PEP is overkill. I see PEPs as more related to Python > language changes, rather than library issues (unless the library issue is > far-reaching or fundamental). > > I'd suggest a proposal to distutils-sig (basically, just a repost of your > message with the suggested code in it), with a suggested discussion period > of (say) 1 week. If no-one raises a showstopper objection in that time, > check it in. Any discussion over the exact details of features should be > noted but treated as requests for changes which can be submitted as patches > *after* the release (unless they are small and non-controversial, when they > can just be done). > > Actually, I'd just check it in and wait for comments, but I like to live > dangerously... :-) > It seems the "official" way to do it would be to prepare the source and then upload it as a patch to sourceforge. At least I would like the people on python-dev to comment (most of them aren't subscribed to distutils-sig). One important point IMO: No additional code should be checked in without proper documentation! Does anyone want to help here? > > Anyway, lets try to clear this *fast*. > > Yes. > > Treating your suggested code as a proposal, I've a couple of comments. None > to be treated as showstoppers - count me as +1 on checking this in > regardless - but possibly worth consideration: > > 1. What happens if there are no tests? Rather than silently doing nothing, > I'd suggest printing "No tests defined", to act as a reminder that tests > would be nice... Hmm. Not sure... > > 2. What is the code_coverage module? It's not standard, so I guess it should > not be included in a standard distutils command. Although including code > coverage reports in test results is nice, so using it if it is available, > and skipping the coverage tests if not, might be good. I should have removed them before posting the code, they were more or less experimental (although they worked nice when I tried them). Instead I would like to refactor the code a little, so that (in custom subclasses) it would be easier to change/extend the tests. Thomas From Paul.Moore@atosorigin.com Wed Jan 16 10:28:05 2002 From: Paul.Moore@atosorigin.com (Moore, Paul) Date: Wed Jan 16 10:28:05 2002 Subject: [Distutils] test suite support Message-ID: <714DFA46B9BBD0119CD000805FC1F53B01B5B17D@UKRUX002.rundc.uk.origin-it.com> From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > It seems the "official" way to do it would be to prepare the source > and then upload it as a patch to sourceforge. At least I would like > the people on python-dev to comment (most of them aren't subscribed > to distutils-sig). Good point - that would make sense. > One important point IMO: No additional code should be checked in > without proper documentation! Does anyone want to help here? True. As I'm pushing for this, I should offer to help. Unfortunately, I'm extremely busy the rest of this week and the next two, so if someone else can do it that would be good. Otherwise, I'll try to do something in early February. > > I'd suggest printing "No tests defined", to act as a > > reminder that tests would be nice... > Hmm. Not sure... How about keeping track of how many tests get run and printing "X tests completed" at the end? I guess it depends - I just worry that if people type "python setup.py test" and see no feedback, this will feel more reassuring than it should. Paul. From mal@lemburg.com Wed Jan 16 13:52:00 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed Jan 16 13:52:00 2002 Subject: [Distutils] test suite support References: <714DFA46B9BBD0119CD000805FC1F53B01B5B17D@UKRUX002.rundc.uk.origin-it.com> Message-ID: <3C45CC31.F116A55D@lemburg.com> "Moore, Paul" wrote: > > From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > > It seems the "official" way to do it would be to prepare the source > > and then upload it as a patch to sourceforge. At least I would like > > the people on python-dev to comment (most of them aren't subscribed > > to distutils-sig). > > Good point - that would make sense. Instead of discussing what the "right" way to do testing really is, why not simply leave this decision to the package author and only ask for an entry point, e.g. setup(... tests = [ TestSuite('mytests', run=myunittests.run, verbose=1), TestSuite('moretests', run=mymodule._test) ], ...) The only question I see coming up is whether to run tests automatically or only at request. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From knight@baldmt.com Wed Jan 16 15:04:00 2002 From: knight@baldmt.com (Steven Knight) Date: Wed Jan 16 15:04:00 2002 Subject: [Distutils] test suite support In-Reply-To: <3C45CC31.F116A55D@lemburg.com> Message-ID: > > > It seems the "official" way to do it would be to prepare the source > > > and then upload it as a patch to sourceforge. At least I would like > > > the people on python-dev to comment (most of them aren't subscribed > > > to distutils-sig). > > > > Good point - that would make sense. > > Instead of discussing what the "right" way to do testing really > is, why not simply leave this decision to the package author and > only ask for an entry point, e.g. > > setup(... > tests = [ TestSuite('mytests', run=myunittests.run, verbose=1), > TestSuite('moretests', run=mymodule._test) ], > ...) > > The only question I see coming up is whether to run tests > automatically or only at request. Hear, hear. There are too many different testing methodologies to try to pick the "right" one for distutils to support. Within my project alone (SCons) we use two separate testing methodologies, PyUnit for per-module unit tests and a TestCmd.py module for end-to-end command testing. Anything more restrictive than a simple, generic "run the tests" interface would be a problem. --SK From Achim.Gaedke@uni-koeln.de Thu Jan 17 09:52:16 2002 From: Achim.Gaedke@uni-koeln.de (Achim Gaedke) Date: Thu Jan 17 09:52:16 2002 Subject: [Distutils] test suite support References: Message-ID: <3C46E416.2CB9AA0F@uni-koeln.de> (resent to mailinglist because of mailer errors) Steven Knight wrote: > > > Instead of discussing what the "right" way to do testing really > > is, why not simply leave this decision to the package author and > > only ask for an entry point, e.g. > > > > setup(... > > tests = [ TestSuite('mytests', run=myunittests.run, verbose=1), > > TestSuite('moretests', run=mymodule._test) ], > > ...) > > > > The only question I see coming up is whether to run tests > > automatically or only at request. > > Hear, hear. There are too many different testing methodologies to try > to pick the "right" one for distutils to support. Within my project > alone (SCons) we use two separate testing methodologies, PyUnit for > per-module unit tests and a TestCmd.py module for end-to-end command > testing. Anything more restrictive than a simple, generic "run the > tests" interface would be a problem. One likes PyUnit, one doesn't, one likes doctest, one doesn't... Tests can be done for two logical units: For the package as whole and per module: - So we should have a "test" attribute to each extension and py_module defined in setup.py, which provides a customized test routine. - and there should be the test command that looks a a global variable for customized tests or tries to call the test method for each module. Sorry, I can't provide code, I am just new to PyUnit and to distutils. This is the reason why I asked this list. Thank you for that amazing echo. This is the reason, why I call attention to the need of using standard utilities - PyUnit seems to me a standard or default for testing. Imo doctest intends to test documentation and reference example code and not "boring" test routines. But once more: Thanks and a fast solution. From akuchlin@mems-exchange.org Thu Jan 17 11:48:14 2002 From: akuchlin@mems-exchange.org (Andrew Kuchling) Date: Thu Jan 17 11:48:14 2002 Subject: [Distutils] test suite support In-Reply-To: <3C46E416.2CB9AA0F@uni-koeln.de> References: <3C46E416.2CB9AA0F@uni-koeln.de> Message-ID: <20020117164759.GA2162@ute.mems-exchange.org> On Thu, Jan 17, 2002 at 03:47:50PM +0100, Achim Gaedke wrote: >- PyUnit seems to me a standard or default for testing. > >Imo doctest intends to test documentation and reference example code and not >"boring" test routines. Not at all; there are people who use primarily doctest, and I use a completely different unit test module that isn't included with Python at all. --amk From jjl@pobox.com Thu Jan 17 16:19:00 2002 From: jjl@pobox.com (John J. Lee) Date: Thu Jan 17 16:19:00 2002 Subject: [Distutils] missing Python symbols Message-ID: I'm getting complaints from mingw32's gcc about references to Python symbols, which I would have thought would have been taken care of by distutils' use of -lpython21, below. Why isn't this working? Sorry for the line mangling below. running build_ext building '_recode' extension creating build\temp.win32-2.1\Release d:\ProgramFiles\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Ibibtex -Iwin -Iwin/src -Iwin/lib - Iwin/intl -Ic:\Python21\Include -c compiled/recodemodule.c -o build\temp.win32-2.1\Release\recode module.o writing build\temp.win32-2.1\Release\_recode.def d:\ProgramFiles\mingw\bin\gcc.exe -mno-cygwin -mdll -static -s build\temp.win32-2.1\Release\recod emodule.o build\temp.win32-2.1\Release\_recode.def -Lc:\Python21\libs -Lbuild\temp.win32-2.1 -lpy thon21 -lrecode -o build\lib.win32-2.1\_recode.pyd build\temp.win32-2.1\Release\recodemodule.o(.text+0xd9):recodemodule.c: undefined reference to `_ imp__PyExc_IOError' build\temp.win32-2.1\Release\recodemodule.o(.text+0x1d1):recodemodule.c: undefined reference to ` _imp__PyExc_IOError' build\temp.win32-2.1\Release\recodemodule.o(.text+0x203):recodemodule.c: undefined reference to ` _imp__PyType_Type' error: command 'gcc' failed with exit status 1 Thanks for any help John From R.Liebscher@gmx.de Fri Jan 18 02:44:01 2002 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Fri Jan 18 02:44:01 2002 Subject: [Distutils] missing Python symbols References: Message-ID: <3C47D28F.A8F3322C@gmx.de> "John J. Lee" wrote: > > I'm getting complaints from mingw32's gcc about references to Python > symbols, which I would have thought would have been taken care of by > distutils' use of -lpython21, below. Why isn't this working? > > Sorry for the line mangling below. > > running build_ext > building '_recode' extension > creating build\temp.win32-2.1\Release > d:\ProgramFiles\mingw\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Ibibtex > -Iwin -Iwin/src -Iwin/lib - > Iwin/intl -Ic:\Python21\Include -c compiled/recodemodule.c -o > build\temp.win32-2.1\Release\recode > module.o > writing build\temp.win32-2.1\Release\_recode.def > d:\ProgramFiles\mingw\bin\gcc.exe -mno-cygwin -mdll -static -s > build\temp.win32-2.1\Release\recod > emodule.o build\temp.win32-2.1\Release\_recode.def -Lc:\Python21\libs > -Lbuild\temp.win32-2.1 -lpy > thon21 -lrecode -o build\lib.win32-2.1\_recode.pyd > build\temp.win32-2.1\Release\recodemodule.o(.text+0xd9):recodemodule.c: > undefined reference to `_ > imp__PyExc_IOError' > build\temp.win32-2.1\Release\recodemodule.o(.text+0x1d1):recodemodule.c: > undefined reference to ` > _imp__PyExc_IOError' > build\temp.win32-2.1\Release\recodemodule.o(.text+0x203):recodemodule.c: > undefined reference to ` > _imp__PyType_Type' > error: command 'gcc' failed with exit status 1 > > Thanks for any help > > John > Look at http://mail.python.org/pipermail/distutils-sig/2001-September/002590.html Kind regards Rene Liebscher From jeremy@zope.com Fri Jan 18 10:15:00 2002 From: jeremy@zope.com (Jeremy Hylton) Date: Fri Jan 18 10:15:00 2002 Subject: [Distutils] making setup less chatty by default Message-ID: <15431.26703.702447.958917@gondolin.digicool.com> I would like to see the setup() command and distutils in general by less chatty by default. I've contributed a very rough patch that enables this for the one place where it bothers me the most: http://sourceforge.net/tracker/?func=detail&atid=305470&aid=504889&group_id=5470 In discussion on that patch, which, incidentally, isn't something I planned to checkin myself, Marc-Andre disagrees with the suggestion that this be the default. Even if it isn't the default, I'd like to see enough flexibility to have different levels of verbosity. The current code supports two extremes, quiet and verbose, but I don't find either of these very useful. I agree that each has their place and I don't think anything should be changed to prevent them as options, but I'd like to see more options. The chattiness that I don't find helpful is all the messages about things being skipped or not copied because they're up-to-date. I don't find this helpful because my typical usage is to make a change to one or two files, re-build, and run some tests. When I build, I'd like to see confirmation that my changes were built. I don't care to see hundreds of lines of output about things I didn't change. Here's one anecdote that describes the kinds of uses I have in mind. I work on a StandaloneZODB package; when I make no changes and run setup.py build, it produces 158 lines of output. That's too much to fit on my screen, and scrolling back even line looks the same :-). When I make changes, it's important to see what gets updated. The various C extensions have a bunch of internal dependencies, e.g. a .c file on a .h file. Distutils doesn't track these dependencies, so I sometimes need to manually delete .o and .so files when the right targets don't get rebuilt. In this case, I don't want to wade through lots of output to make sure the right things got built. In the patch discussion, I also note that the code seems internally confused about what verbose means. It guarantees that verbose (the attribute) is a boolean value, either 0 or 1, but it compares verbose to the variable level using > and >=. I think that should be cleaned up regardless, as it makes the code confusing. Along similar lines, distutils appears to have some helper methods like announce() that are used for output. But lots of code just uses print. So responsibility for checking the verbose flag is spread throughout the code base. I think announce() and the like is probably a good idea, but can't tell if there is a good reason that it isn't used systematically. What's the next step? I have a rough patch of a feature I'd like to see. We need to reach some decision about whether the feature is good, then what the right default is. Jeremy From robin@jessikat.fsnet.co.uk Fri Jan 18 12:48:14 2002 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Fri Jan 18 12:48:14 2002 Subject: [Distutils] making setup less chatty by default In-Reply-To: <15431.26703.702447.958917@gondolin.digicool.com> References: <15431.26703.702447.958917@gondolin.digicool.com> Message-ID: In article <15431.26703.702447.958917@gondolin.digicool.com>, Jeremy Hylton writes >I would like to see the setup() command and distutils in general by >less chatty by default. I've contributed a very rough patch that >enables this for the one place where it bothers me the most: ..... >What's the next step? I have a rough patch of a feature I'd like to >see. We need to reach some decision about whether the feature is >good, then what the right default is. > >Jeremy I agree with the intent of your patch and with the idea of cleaning up the way messages are issued. -- Robin Becker From thomas.heller@ion-tof.com Fri Jan 18 14:28:01 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Fri Jan 18 14:28:01 2002 Subject: [Distutils] making setup less chatty by default References: <15431.26703.702447.958917@gondolin.digicool.com> Message-ID: <065601c1a056$285a1b30$e000a8c0@thomasnotebook> From: "Robin Becker" > In article <15431.26703.702447.958917@gondolin.digicool.com>, Jeremy > Hylton writes > >I would like to see the setup() command and distutils in general by > >less chatty by default. I've contributed a very rough patch that > >enables this for the one place where it bothers me the most: > ..... > >What's the next step? I have a rough patch of a feature I'd like to > >see. We need to reach some decision about whether the feature is > >good, then what the right default is. > > > >Jeremy > > I agree with the intent of your patch and with the idea of cleaning up > the way messages are issued. Same for me. Thomas From tim.one@home.com Sat Jan 19 02:03:01 2002 From: tim.one@home.com (Tim Peters) Date: Sat Jan 19 02:03:01 2002 Subject: [Distutils] test suite support In-Reply-To: <20020117164759.GA2162@ute.mems-exchange.org> Message-ID: [Achim Gaedke] > Imo doctest intends to test documentation and reference example > code and not "boring" test routines. [Andrew Kuchling] > Not at all; there are people who use primarily doctest, You're both right. doctest (and I should know ) was indeed *intended* to verify examples in docstrings, and that's all. The only major feature I ever added was Christian Tismer's suggestion to add a magical __test__ dict, and that turned out to be a powerful hook allowing to build all sorts of frameworks on top. However, I have so far refused to do the latter: the unittest framework drives me mad with frustration (people layer test classes is such convoluted ways you can't follow the logic anymore, and the business of not showing *any* info beyond "ERROR" for unexpected exceptions until the end of the whole run has wasted countless hours of my time). But I don't have a better framework in mind, so screw it . > and I use a completely different unit test module that isn't included > with Python at all. Chicken. From dubois1@llnl.gov Sun Jan 20 15:13:00 2002 From: dubois1@llnl.gov (Paul F. Dubois) Date: Sun Jan 20 15:13:00 2002 Subject: [Distutils] making setup less chatty by default In-Reply-To: <065601c1a056$285a1b30$e000a8c0@thomasnotebook> Message-ID: <000101c1a1ee$4ee36ba0$0c01a8c0@freedom> Allow me to add my voice to Jeremy's. I think he has this right. From mal@lemburg.com Mon Jan 21 03:58:02 2002 From: mal@lemburg.com (M.-A. Lemburg) Date: Mon Jan 21 03:58:02 2002 Subject: [Distutils] making setup less chatty by default References: <000101c1a1ee$4ee36ba0$0c01a8c0@freedom> Message-ID: <3C4BD88B.F2261802@lemburg.com> Just to clarify: I don't have objections as to clean up the distutils self.verbose interface. Indeed, I would prefer to have clearly defined verbosity levels to choose from, e.g. verbose 0 - give information about commands being run and what part of the cake they are working on (and nothing more) verbose 1 - give details about what the commands actually do (or don't do, e.g. skipping actions) verbose 2 - any extra information which might be helpful The interface should work much like Python's: -v = level 1 -vv = level 2. Note that warnings and errors should *always* be displayed (we might want to add verbose levels -1 and -2 which are set by providing a command line option -q and -qq resp. to force keeping quiet in these areas too). Jeremy wants to move the "don't so" messages one level up. If the above scheme gets implemented, I'd be -0 on that one... I still believe that skip notices are just as important as build notices, but YMMV. Gotta run, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/ From mwh@python.net Mon Jan 21 05:18:01 2002 From: mwh@python.net (Michael Hudson) Date: Mon Jan 21 05:18:01 2002 Subject: [Distutils] making setup less chatty by default In-Reply-To: "M.-A. Lemburg"'s message of "Mon, 21 Jan 2002 09:59:55 +0100" References: <000101c1a1ee$4ee36ba0$0c01a8c0@freedom> <3C4BD88B.F2261802@lemburg.com> Message-ID: <2mpu44xb3v.fsf@starship.python.net> "M.-A. Lemburg" writes: > Just to clarify: I don't have objections as to clean up the > distutils self.verbose interface. Indeed, I would prefer to > have clearly defined verbosity levels to choose from, e.g. Me too. I'll even write the code, so long as noone's in too much of a hurry. > verbose 0 - give information about commands being run and > what part of the cake they are working on (and > nothing more) I think a reasonable guide for this level is how much noise "make" makes, i.e. print commandline to be executed, echo command output, don't mention skips. > verbose 1 - give details about what the commands actually do > (or don't do, e.g. skipping actions) > verbose 2 - any extra information which might be helpful > > The interface should work much like Python's: -v = level 1 > -vv = level 2. > > Note that warnings and errors should *always* be displayed > (we might want to add verbose levels -1 and -2 which are > set by providing a command line option -q and -qq resp. to > force keeping quiet in these areas too). We have -q already, don't we? > Jeremy wants to move the "don't so" messages one level > up. If the above scheme gets implemented, I'd be > -0 on that one... I still believe that skip notices are > just as important as build notices, but YMMV. I don't really care. Can't you bodge this with a .pydistutils.cfg file? [global] verbose: 1 or whatever. Cheers, M. -- The "of course, while I have no problem with this at all, it's surely too much for a lesser being" flavor of argument always rings hollow to me. -- Tim Peters, 29 Apr 1998 From robin@jessikat.fsnet.co.uk Mon Jan 21 05:26:01 2002 From: robin@jessikat.fsnet.co.uk (Robin Becker) Date: Mon Jan 21 05:26:01 2002 Subject: [Distutils] making setup less chatty by default In-Reply-To: <3C4BD88B.F2261802@lemburg.com> References: <000101c1a1ee$4ee36ba0$0c01a8c0@freedom> <3C4BD88B.F2261802@lemburg.com> Message-ID: In article <3C4BD88B.F2261802@lemburg.com>, M.-A. Lemburg writes >Just to clarify: I don't have objections as to clean up the >distutils self.verbose interface. Indeed, I would prefer to >have clearly defined verbosity levels to choose from, e.g. > >verbose 0 - give information about commands being run and > what part of the cake they are working on (and > nothing more) >verbose 1 - give details about what the commands actually do > (or don't do, e.g. skipping actions) >verbose 2 - any extra information which might be helpful > >The interface should work much like Python's: -v = level 1 >-vv = level 2. > >Note that warnings and errors should *always* be displayed >(we might want to add verbose levels -1 and -2 which are >set by providing a command line option -q and -qq resp. to >force keeping quiet in these areas too). > .... I would definitely want an option to force complete quietness unless errors/warnings are displayed. so -1 display only warnings and errors (not any other information) -2 display only errors -3 display nothing (ie use exit status to communicate problems). -- Robin Becker From jeremy@alum.mit.edu Mon Jan 21 08:51:00 2002 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Mon Jan 21 08:51:00 2002 Subject: [Distutils] making setup less chatty by default In-Reply-To: <2mpu44xb3v.fsf@starship.python.net> References: <000101c1a1ee$4ee36ba0$0c01a8c0@freedom> <3C4BD88B.F2261802@lemburg.com> <2mpu44xb3v.fsf@starship.python.net> Message-ID: <15436.7909.452029.306063@gondolin.digicool.com> >>>>> "MH" == Michael Hudson writes: MH> "M.-A. Lemburg" writes: >> Just to clarify: I don't have objections as to clean up the >> distutils self.verbose interface. Indeed, I would prefer to have >> clearly defined verbosity levels to choose from, e.g. MH> Me too. I'll even write the code, so long as noone's in too MH> much of a hurry. By tea time should be just fine . Seriously, though, we've got plenty of time before 2.3, and I've got my monkey patch to keep me (and distutils) quiet for now. When might you get to it? Jeremy From mwh@python.net Mon Jan 21 08:56:01 2002 From: mwh@python.net (Michael Hudson) Date: Mon Jan 21 08:56:01 2002 Subject: [Distutils] making setup less chatty by default In-Reply-To: Jeremy Hylton's message of "Mon, 21 Jan 2002 09:00:05 -0500" References: <000101c1a1ee$4ee36ba0$0c01a8c0@freedom> <3C4BD88B.F2261802@lemburg.com> <2mpu44xb3v.fsf@starship.python.net> <15436.7909.452029.306063@gondolin.digicool.com> Message-ID: <2my9irizat.fsf@starship.python.net> Jeremy Hylton writes: > >>>>> "MH" == Michael Hudson writes: > > MH> "M.-A. Lemburg" writes: > >> Just to clarify: I don't have objections as to clean up the > >> distutils self.verbose interface. Indeed, I would prefer to have > >> clearly defined verbosity levels to choose from, e.g. > > MH> Me too. I'll even write the code, so long as noone's in too > MH> much of a hurry. > > By tea time should be just fine . I'm sure there's an appropriate Douglas Adams' quote that could go here, but I can't think of one off the top of my head. > Seriously, though, we've got plenty of time before 2.3, and I've got > my monkey patch to keep me (and distutils) quiet for now. When might > you get to it? Hard to say. I have an increasingly large pile of paper next to me as I print out the distutils sources for offline digestion. Couple of weeks? A month? Cheers, M. -- This makes it possible to pass complex object hierarchies to a C coder who thinks computer science has made no worthwhile advancements since the invention of the pointer. -- Gordon McMillan, 30 Jul 1998 From jeremy@alum.mit.edu Mon Jan 21 09:08:01 2002 From: jeremy@alum.mit.edu (Jeremy Hylton) Date: Mon Jan 21 09:08:01 2002 Subject: [Distutils] making setup less chatty by default In-Reply-To: <2my9irizat.fsf@starship.python.net> References: <000101c1a1ee$4ee36ba0$0c01a8c0@freedom> <3C4BD88B.F2261802@lemburg.com> <2mpu44xb3v.fsf@starship.python.net> <15436.7909.452029.306063@gondolin.digicool.com> <2my9irizat.fsf@starship.python.net> Message-ID: <15436.8910.149544.216664@gondolin.digicool.com> >>>>> "MH" == Michael Hudson writes: MH> Hard to say. I have an increasingly large pile of paper next to MH> me as I print out the distutils sources for offline digestion. MH> Couple of weeks? A month? Sounds fine to me. i'll-also-assign-all-distuils-bugs-to-you-ly y'rs, Jeremy From jjl@pobox.com Tue Jan 22 08:53:01 2002 From: jjl@pobox.com (John J. Lee) Date: Tue Jan 22 08:53:01 2002 Subject: [Distutils] missing Python symbols In-Reply-To: <3C47D28F.A8F3322C@gmx.de> Message-ID: On Fri, 18 Jan 2002, Rene Liebscher wrote: > "John J. Lee" wrote: > > > > I'm getting complaints from mingw32's gcc about references to Python > > symbols, which I would have thought would have been taken care of by > > distutils' use of -lpython21, below. Why isn't this working? [...] > > Look at > > http://mail.python.org/pipermail/distutils-sig/2001-September/002590.html [...] Trouble with pexports: src$ ./pexports.exe //c/winnt/system32/python21.dll > python21.def d:\ProgramFiles\pexports-0.42h\src\pexports.exe: //c/winnt/system32/python21.dll: could not load PE image I recompiled (with mingw's gcc), with no effect. What's wrong?? This is just the standard win32 Python 2.1 I'm using here. I've just downloaded Robert Kern's lib2def, but can't try it out here. Still, I don't see why pexports isn't working... John From R.Liebscher@gmx.de Tue Jan 22 11:35:01 2002 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Tue Jan 22 11:35:01 2002 Subject: [Distutils] missing Python symbols References: Message-ID: <3C4D94F7.2781B442@gmx.de> "John J. Lee" wrote: > > On Fri, 18 Jan 2002, Rene Liebscher wrote: > > > "John J. Lee" wrote: > > > > > > I'm getting complaints from mingw32's gcc about references to Python > > > symbols, which I would have thought would have been taken care of by > > > distutils' use of -lpython21, below. Why isn't this working? > [...] > > > > Look at > > > > http://mail.python.org/pipermail/distutils-sig/2001-September/002590.html > [...] > > Trouble with pexports: > > src$ ./pexports.exe //c/winnt/system32/python21.dll > python21.def > d:\ProgramFiles\pexports-0.42h\src\pexports.exe: //c/winnt/system32/python21.dll: could not load PE image I'm not sure, but does this message mean pexports can't load/find the file? Maybe you should try it as pexports.exe 'C:\winnt\system32\python21.dll' Rene > > I recompiled (with mingw's gcc), with no effect. What's wrong?? This is > just the standard win32 Python 2.1 I'm using here. > > I've just downloaded Robert Kern's lib2def, but can't try it out here. > Still, I don't see why pexports isn't working... > > John From jason@tishler.net Tue Jan 22 12:07:00 2002 From: jason@tishler.net (Jason Tishler) Date: Tue Jan 22 12:07:00 2002 Subject: [Distutils] Re: cygwin build woes. In-Reply-To: References: Message-ID: <20020122171042.GA952@dothill.com> Michael, On Tue, Jan 22, 2002 at 02:57:45PM +0000, Michael Hudson wrote: > Building from CVS, no shared modules build, because distutils is > looking for libpython2.3.dll, which isn't being built. > > These lines in Lib/distutils/command/build_ext.py are the problem: > > elif sys.platform[:6] == "cygwin": > template = "python%d.%d" > pythonlib = (template % > (sys.hexversion >> 24, (sys.hexversion >> 16) & 0xff)) > # don't extend ext.libraries, it may be shared with other > # extensions, it is a reference to the original list > return ext.libraries + [pythonlib] > > It would be better, IMHO, to write > > elif sys.platform[:6] == "cygwin": > pythonlib = "python" + sys.version[:3] > # don't extend ext.libraries, it may be shared with other > # extensions, it is a reference to the original list > return ext.libraries + [pythonlib] > > as sys.version and VERSION in configure.in are pretty much guaranteed > to be in sync. > > Shall I check this in, or do you have a better idea? The looks OK by me, but I feel that this is a question for the Distutils list. Any opinions on Michael's proposal? Thanks, Jason From jjl@pobox.com Wed Jan 23 17:28:00 2002 From: jjl@pobox.com (John J. Lee) Date: Wed Jan 23 17:28:00 2002 Subject: [Distutils] _spawn_posix fails, command line works?? Message-ID: This is so bizarre I think it has to be something I'm doing wrong, but here goes: Having some trouble linking something on Windows, I tried moving back to linux to see if I could get it working in distutils there first. The actual compilation was working fine on Windows (mingw32). So, back on linux: $ ./setup.py build [...usual stuff...] gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -DHAVE_CONFIG_H=1 -DLOCALEDIR=\"\" -DGNULOCALEDIR=\"\" -DLOCALE_ALIAS_PATH=\"\" -Iwin -Iwin/src -Iwin/lib -Iwin/intl -I/usr/lib/glib/include -c win/src/argmatch.c -o build/temp.linux-i586-2.1/argmatch.o win/src/argmatch.c:0: unterminated string or character constant win/src/argmatch.c:0: possible real start of unterminated constant win/src/argmatch.c:0: unterminated string or character constant win/src/argmatch.c:0: possible real start of unterminated constant win/src/argmatch.c:0: unterminated string or character constant win/src/argmatch.c:0: possible real start of unterminated constant error: command 'gcc' failed with exit status 1 This file is the first one it attempted to compile. OK, I thought, clearly I've messed up the line endings or something. However, to cut the longer story short, if you cut and paste the command distutils claims to be executing (in distutils.spawn._spawn_posix, I guess) onto the command line, it works fine! Looking at argmatch.c, of course, reveals nothing amiss. Line 0 is the first line of a multi-line comment. Still, I can't really bring myself to believe that there is something wrong with _spawn_posix; at least, not enough to try to 'debug' it. Is this problem my fault, or distutils'? Just to make clear: I'm not doing any poking around in distutils' internals in my setup.py: it's just a perfectly standard set of Extension() instances, and a couple of static libs, and the only distutils function I call is setup itself. John From R.Liebscher@gmx.de Thu Jan 24 04:11:39 2002 From: R.Liebscher@gmx.de (Rene Liebscher) Date: Thu Jan 24 04:11:39 2002 Subject: [Distutils] _spawn_posix fails, command line works?? References: Message-ID: <3C4FCFD8.C50D9572@gmx.de> "John J. Lee" wrote: > > This is so bizarre I think it has to be something I'm doing wrong, but > here goes: > > Having some trouble linking something on Windows, I tried moving back to > linux to see if I could get it working in distutils there first. The > actual compilation was working fine on Windows (mingw32). So, back on > linux: > > $ ./setup.py build > [...usual stuff...] > gcc -g -O2 -Wall -Wstrict-prototypes -fPIC -DHAVE_CONFIG_H=1 -DLOCALEDIR=\"\" -DGNULOCALEDIR=\"\" -DLOCALE_ALIAS_PATH=\"\" -Iwin -Iwin/src -Iwin/lib -Iwin/intl -I/usr/lib/glib/include -c win/src/argmatch.c -o build/temp.linux-i586-2.1/argmatch.o > win/src/argmatch.c:0: unterminated string or character constant > win/src/argmatch.c:0: possible real start of unterminated constant > win/src/argmatch.c:0: unterminated string or character constant > win/src/argmatch.c:0: possible real start of unterminated constant > win/src/argmatch.c:0: unterminated string or character constant > win/src/argmatch.c:0: possible real start of unterminated constant > error: command 'gcc' failed with exit status 1 > > This file is the first one it attempted to compile. > > OK, I thought, clearly I've messed up the line endings or something. > However, to cut the longer story short, if you cut and paste the command > distutils claims to be executing (in distutils.spawn._spawn_posix, I > guess) onto the command line, it works fine! > > Looking at argmatch.c, of course, reveals nothing amiss. Line 0 is > the first line of a multi-line comment. > > Still, I can't really bring myself to believe that there is something > wrong with _spawn_posix; at least, not enough to try to 'debug' it. > > Is this problem my fault, or distutils'? > > Just to make clear: I'm not doing any poking around in distutils' > internals in my setup.py: it's just a perfectly standard set of > Extension() instances, and a couple of static libs, and the only distutils > function I call is setup itself. > > John I think the problem is related to the quoting of -DLOCALEDIR=\"\" -DGNULOCALEDIR=\"\" -DLOCALE_ALIAS_PATH=\"\" gcc first processes these defines (preprocessor!), so it is line 0 of the input file. (First line of the file should be get the number 1.) You can simply show this: Create a file x.c: --------------- char x[]=FOO; --------------- Directly typed at the shell $ gcc -E -DFOO=\"\" x.c # 1 "x.c" char x[]= "" ; The quoting what distutils seems to use: $ gcc -E '-DFOO=\"\"' x.c x.c:0: unterminated string or character constant x.c:0: possible real start of unterminated constant # 1 "x.c" char x[]=FOO; The problem must be here the different quoting behavior of distutils for Unix or Windows. (Distutils uses os.execpv and os.spawn here, parameters without ' ' go unquoted to these commands in both cases [file spawn.py]. So these Python functions should be checked too.) (Or there is a difference in the shells or how gcc processes command line parameters.) Maybe someone else can investigate this further. (because I have the next weeks not much time for it.) Kind regards Rene Liebscher From mwh@python.net Thu Jan 24 04:58:06 2002 From: mwh@python.net (Michael Hudson) Date: Thu Jan 24 04:58:06 2002 Subject: [Distutils] _spawn_posix fails, command line works?? In-Reply-To: "John J. Lee"'s message of "Wed, 23 Jan 2002 22:27:21 +0000 (GMT)" References: Message-ID: <2m1yggxea5.fsf@starship.python.net> "John J. Lee" writes: > Is this problem my fault, or distutils'? After reading Rene's reply, I'd say probably yours. But I'm not sure. > Just to make clear: I'm not doing any poking around in distutils' > internals in my setup.py: it's just a perfectly standard set of > Extension() instances, and a couple of static libs, and the only > distutils function I call is setup itself. Can we see it anyway? Cheers, M. -- 40. There are two ways to write error-free programs; only the third one works. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html From jjl@pobox.com Thu Jan 24 16:14:11 2002 From: jjl@pobox.com (John J. Lee) Date: Thu Jan 24 16:14:11 2002 Subject: [Distutils] _spawn_posix fails, command line works?? In-Reply-To: <2m1yggxea5.fsf@starship.python.net> Message-ID: On 24 Jan 2002, Michael Hudson wrote: > "John J. Lee" writes: > > > Is this problem my fault, or distutils'? > > After reading Rene's reply, I'd say probably yours. But I'm not sure. Sorry, would have posted the solution to the list before if I'd noticed Jack Jansen's reply to me was only emailed... it was simply the same problem that you were having, Michael. Something along the lines of: the windows implementation goes through the shell (or cmd.com or whatever it is -- though I was using cygwin + mingw gcc at the time), and the posix impl. uses execvp, so there's no quoting of backslashes needed. This should be fixed in distutils, I think, probably in _nt_quote_args. I suppose any fix should be tested with the various mingw / cygwin and command.com / bash combinations. > > Just to make clear: I'm not doing any poking around in distutils' > > internals in my setup.py: it's just a perfectly standard set of > > Extension() instances, and a couple of static libs, and the only > > distutils function I call is setup itself. > > Can we see it anyway? Don't have it with me, will post it later if it hasn't been sorted out by then. John From jjl@pobox.com Sat Jan 26 17:34:01 2002 From: jjl@pobox.com (John J. Lee) Date: Sat Jan 26 17:34:01 2002 Subject: [Distutils] _spawn_posix fails, command line works?? In-Reply-To: <2m1yggxea5.fsf@starship.python.net> Message-ID: On 24 Jan 2002, Michael Hudson wrote: > "John J. Lee" writes: [...] > > internals in my setup.py: it's just a perfectly standard set of > > Extension() instances, and a couple of static libs, and the only > > distutils function I call is setup itself. > > Can we see it anyway? The relevant bit: from distutils.core import setup, Extension ext_modules = [] c_libraries = [] ... if os.name == "nt": fmt = '\\"%s\\"' elif os.name == "posix": fmt = '\"%s\"' macros = [ ("HAVE_CONFIG_H", 1), ("LOCALEDIR", fmt % (os.environ.get("localedir", ""),)), ("GNULOCALEDIR", fmt % (os.environ.get("gnulocaledir", ""),)), ("LOCALE_ALIAS_PATH", fmt % (os.environ.get("aliaspath", ""),)) ] # libintl (gettext) static lib srcs = glob(join("win", "intl", "*.c")) srcs.remove(join("win", "intl", "cat-compat.c")) intlsrcs = srcs # recode static lib srcs = glob(join("win", "src", "*.c")) srcs.remove(join("win", "src", "ansi2knr.c")) srcs.extend(intlsrcs) lib = "recode", {"sources": srcs, "include_dirs": include_dirs, "macros": macros} c_libraries.append(lib) ... As for a fix for for windows implementation, I don't have the knowledge to say how this should be done in the general case. John From Jack.Jansen@oratrix.nl Sun Jan 27 16:10:05 2002 From: Jack.Jansen@oratrix.nl (Jack Jansen) Date: Sun Jan 27 16:10:05 2002 Subject: [Distutils] Path conversion for package_dir missing Message-ID: <7F2C8C28-1367-11D6-9CBF-003065517236@oratrix.nl> Folks, I just submitted a bug report (509288) that the path conversion that needs to be done for all pathnames, converting from URLs (or unix pathnames, depending on your point of view) to local convention is missing for package_dir. I've looked at it for a while, but the distutils architecture is simply too elusive for me: I wouldn't have a clue where to insert the conversion. I don't even understand how the setup() keyword argument gets passed on to the other layers of distutils. Could someone else have a look, please? This problem means the newest Numeric doesn't build on the Mac anymore. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - From thomas.heller@ion-tof.com Mon Jan 28 04:46:20 2002 From: thomas.heller@ion-tof.com (Thomas Heller) Date: Mon Jan 28 04:46:20 2002 Subject: [Distutils] Path conversion for package_dir missing References: <7F2C8C28-1367-11D6-9CBF-003065517236@oratrix.nl> Message-ID: <04e801c1a7e0$4df0bca0$e000a8c0@thomasnotebook> From: "Jack Jansen" > Folks, > I just submitted a bug report (509288) that the path conversion > that needs to be done for all pathnames, converting from URLs > (or unix pathnames, depending on your point of view) to local > convention is missing for package_dir. Does this patch fix the problem? Thomas Index: build_py.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/distutils/command/build_py.py,v retrieving revision 1.34 diff -c -r1.34 build_py.py *** build_py.py 2001/12/06 20:59:17 1.34 --- build_py.py 2002/01/28 09:38:55 *************** *** 12,17 **** --- 12,18 ---- from distutils.core import Command from distutils.errors import * + from distutils.util import convert_path class build_py (Command): *************** *** 50,56 **** # options -- list of packages and list of modules. self.packages = self.distribution.packages self.py_modules = self.distribution.py_modules ! self.package_dir = self.distribution.package_dir # Ick, copied straight from install_lib.py (fancy_getopt needs a # type system! Hell, *everything* needs a type system!!!) --- 51,59 ---- # options -- list of packages and list of modules. self.packages = self.distribution.packages self.py_modules = self.distribution.py_modules ! self.package_dir = {} ! for name, path in self.distribution.package_dir.items(): ! self.package_dir[name] = convert_path(path) # Ick, copied straight from install_lib.py (fancy_getopt needs a # type system! Hell, *everything* needs a type system!!!) From mwh@python.net Mon Jan 28 05:14:01 2002 From: mwh@python.net (Michael Hudson) Date: Mon Jan 28 05:14:01 2002 Subject: [Distutils] _spawn_posix fails, command line works?? In-Reply-To: "John J. Lee"'s message of "Sat, 26 Jan 2002 22:32:56 +0000 (GMT)" References: Message-ID: <2mk7u2941r.fsf@starship.python.net> "John J. Lee" writes: > On 24 Jan 2002, Michael Hudson wrote: > > > "John J. Lee" writes: > [...] > > > internals in my setup.py: it's just a perfectly standard set of > > > Extension() instances, and a couple of static libs, and the only > > > distutils function I call is setup itself. > > > > Can we see it anyway? > > The relevant bit: > > > from distutils.core import setup, Extension > > ext_modules = [] > c_libraries = [] > > ... > > if os.name == "nt": > fmt = '\\"%s\\"' > elif os.name == "posix": > fmt = '\"%s\"' What happens if you change this to fmt = "%s" ? Cheers, M. -- 112. Computer Science is embarrassed by the computer. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html From jjl@pobox.com Thu Jan 31 17:00:15 2002 From: jjl@pobox.com (John J. Lee) Date: Thu Jan 31 17:00:15 2002 Subject: [Distutils] _spawn_posix fails, command line works?? In-Reply-To: <2mk7u2941r.fsf@starship.python.net> Message-ID: On 28 Jan 2002, Michael Hudson wrote: > "John J. Lee" writes: [...] > > if os.name == "nt": > > fmt = '\\"%s\\"' > > elif os.name == "posix": > > fmt = '\"%s\"' > > What happens if you change this to > > fmt = "%s" I suppose you mean '"%s"'? Yes, that's what I should have had in the "posix" part of the if statement (though I don't much care at the moment, since I've still to get the thing to work without segfaulting on windows). The confusing part was the difference in behaviour between windows and unix -- or have I missed your point? John