Mailman 3 January 2002 - Distutils-SIG

missing Python symbols
by John J. Lee Jan. 22, 2002

Jan. 22, 2002

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

2 3

Re: [Distutils] making setup less chatty by default
by Michael Hudson Jan. 21, 2002

Jan. 21, 2002

Jeremy Hylton <jeremy(a)alum.mit.edu> writes: > >>>>> "MH" == Michael Hudson <mwh(a)python.net> writes: > > MH> "M.-A. Lemburg" <mal(a)lemburg.com> 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 <wink>. 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

2 1

Re: [Distutils] making setup less chatty by default
by Michael Hudson Jan. 21, 2002

Jan. 21, 2002

"M.-A. Lemburg" <mal(a)lemburg.com> 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

2 1

making setup less chatty by default
by Jeremy Hylton Jan. 21, 2002

Jan. 21, 2002

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… 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

5 5

RE: [Distutils] test suite support
by Moore, Paul Jan. 19, 2002

Jan. 19, 2002

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.

6 5

RE: [Distutils] test suite support
by Moore, Paul Jan. 16, 2002

Jan. 16, 2002

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.

2 1

RE: [Distutils] test suite support
by Moore, Paul Jan. 16, 2002

Jan. 16, 2002

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.

2 1

test suite support
by Achim Gaedke Jan. 16, 2002

Jan. 16, 2002

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 ?

4 6

Re: [Distutils] Possible Distutils shell processing bug
by Michael Hudson Jan. 14, 2002

Jan. 14, 2002

"Brian Quinlan" <brian(a)sweetapp.com> 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 <Python.h> 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

1 0

Re: [Distutils] Possible Distutils shell processing bug
by Michael Hudson Jan. 14, 2002

Jan. 14, 2002

"Brian Quinlan" <brian(a)sweetapp.com> 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

3 2