Mailman 3 June 2002 - Python-Dev

Re: [Python-Dev] addressing distutils inability to track file dependencies
by Michael Hudson 14 Jun '02

14 Jun '02

Andrew Kuchling <akuchlin(a)mems-exchange.org> writes: > On Fri, Jun 14, 2002 at 11:10:46AM +0100, Michael Hudson wrote: > >Yeah, this area sucks. It interacts v. badly with umask, too. Maybe > >I'll work on this bug instead on my next train journey... installing > >shared libraries with something like copy_tree is gross. > > Out of curiosity, why? Dunno. It just strikes me as a really bad idea. If the linker produces other cruft you'll end up installing that too. It's certainly possible that core files could get installed, if you've run tests in build/lib.foo/. > I've had the patch below sitting in my copy of the tree forever, but > haven't gotten around to checking whether it fixes the umask-related > bug: I think it should, though. I think I tried that and it didn't work, but can't remember all that clearly. Cheers, M. -- As it seems to me, in Perl you have to be an expert to correctly make a nested data structure like, say, a list of hashes of instances. In Python, you have to be an idiot not to be able to do it, because you just write it down. -- Peter Norvig, comp.lang.functional

2 1

Re: [Python-Dev] addressing distutils inability to track file dependencies
by Fredrik Lundh 14 Jun '02

14 Jun '02

alex wrote: > > cycles. I still haven't found a way to get the damn thing to just build > > my extension and copy it to the current directory, so I can run the > > test scripts. > > I haven't even looked for such a way, since going to site-packages is > no problem for me. If I was developing on a Python installation shared > by several users I'd no doubt feel differently about it. you only work on a single project too, I assume. I tend to prefer not to install a broken extension in my machine's default install, in case I have to switch to another project... (and switching between projects is all I seem to do these days ;-) (and I maintain too many modules to afford to install a separate python interpreter for each one of them...) </F>

3 2

Re: [Python-Dev] addressing distutils inability to track file dependencies
by Michael Hudson 14 Jun '02

14 Jun '02

"Thomas Heller" <thomas.heller(a)ion-tof.com> writes: > Then there's Berthold Höllmanns test-command he posted to the > distutils sig, which internally runs the 'build' command, then extends > sys.path by build_purelib, build_platlib, and the test-directory, and > finally runs the tests in the test-directory files. You could have a variant of that that just ran a code.InteractiveInterpreter. $ python setup.py play-around Cheers, M. -- 31. Simplicity does not precede complexity, but follows it. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

1 0

Re: [Python-Dev] addressing distutils inability to track file dependencies
by Michael Hudson 14 Jun '02

14 Jun '02

"Fredrik Lundh" <fredrik(a)pythonware.com> writes: > alex wrote: > > > The "problem" (:-) is that it's great at just building extensions, = > too. > >=20 > > python2.1 setup.py install, python2.2 setup.py install, python2.3 = > setup.py=20 > > install, and hey pronto, I have my extension built and installed on = > all=20 > > Python versions I want to support, ready for testing. Hard to beat!-) > > does your code always work right away? > > I tend to use an incremental approach, with lots of edit-compile-run > cycles. I still haven't found a way to get the damn thing to just build > my extension and copy it to the current directory, so I can run the > test scripts. > > does anyone here know how to do that, without having to resort to > ugly wrapper batch files/shell scripts? Nope. I guess class install_local(distutils.command.install.install): ... would be one way. Perhaps it should be built in. > (distutils is also a pain to use with a version management system > that marks files in the repository as read-only; distutils copy function > happily copies all the status bits. but the remove function refuses to > remove files that are read-only, even if the files have been created > by distutils itself...) Yeah, this area sucks. It interacts v. badly with umask, too. Maybe I'll work on this bug instead on my next train journey... installing shared libraries with something like copy_tree is gross. Cheers, M. -- Counting lines is probably a good idea if you want to print it out and are short on paper, but I fail to see the purpose otherwise. -- Erik Naggum, comp.lang.lisp

2 1

Re: [Python-Dev] addressing distutils inability to track file dependencies
by Fredrik Lundh 14 Jun '02

14 Jun '02

> the following is a bit more reliable (windows version): > > rd /s /q build > python setup.py build > rd /s /q install > python setup.py install --prefix install > copy install\*.pyd . except that the PYD ends up under install\lib\site-packages in some versions of distutils, of course... brute-force workaround: copy install\*.pyd . copy install\lib\site-packages\*.pyd . </F>

1 0

Re: [Python-Dev] addressing distutils inability to track file dependencies
by Michael Hudson 14 Jun '02

14 Jun '02

martin(a)v.loewis.de (Martin v. Loewis) writes: > Jeremy Hylton <jeremy(a)zope.com> writes: > > > Only if distutils grows a way to specify all those dependencies. Once > > you've specified them, I'm not sure why it is difficult to check them > > in Python code instead of relying on make. > > I believe people normally want their build process to know > dependencies without any specification of dependencies. Instead, the > build process should know what the dependencies are by looking at the > source files. > > For C, there are two ways to do that: you can either scan the sources > yourself for include statements, or you can let the compiler dump > dependency lists into files. > > The latter is only supported for some compilers, but it would help > enourmously: when compiling the first time, you know for sure that you > will need to compile. When compiling the second time, you read the > dependency information generated the first time, to determine whether > any of the included headers has changed. If that is not the case, you > can skip rebuilding. If you do rebuild, the dependency information > will be updated automatically (since the change might have been to add > an include). $ cd ~/src/sf/python/dist/src/Lib/distutils/command/ $ ls -l build_dep.py -rw-rw-r-- 1 mwh mwh 763 Apr 13 11:18 build_dep.py Had that idea. Didn't get very far with it, though. Maybe on the train to EuroPython... Cheers, M. -- The gripping hand is really that there are morons everywhere, it's just that the Americon morons are funnier than average. -- Pim van Riezen, alt.sysadmin.recovery

1 0

Updates to bsddb and dbm module build process
by Skip Montanaro 13 Jun '02

13 Jun '02

Would someone like to take a look at the diff file attached to this patch? http://python.org/sf/553108 I think it's complete except for a note in Misc/NEWS. I'd assign it to Barry, but I understand he's a bit busy these days. Skip

1 0

Design Patterns quick reference (was Re: textwrap.py)
by David Goodger 13 Jun '02

13 Jun '02

Greg Ward wrote: > design patterns are great, as long as everyone has a copy of *Design > Patterns* on their desk. ;-) For those of us who don't, here's a free and nearly-complete (20 patterns) quick reference: http://www.netobjectives.com/dpexplained/download/dpmatrix.pdf . Printed double-sided, it makes a good memory jogger. -- David Goodger <goodger(a)users.sourceforge.net> Open-source projects: - Python Docutils: http://docutils.sourceforge.net/ (includes reStructuredText: http://docutils.sf.net/rst.html) - The Go Tools Project: http://gotools.sourceforge.net/

1 0

doc strings patch
by Gustavo Niemeyer 13 Jun '02

13 Jun '02

Could someone please check out patch number 568124? It's a simple patch. OTOH, it's huge, and may break shortly if not applied. Thank you! -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

2 1

change to compiler implementations
by Jeremy Hylton 13 Jun '02

13 Jun '02

I just checked in two sets of changes to distutils. I refactored in the implementation of compile() methods and I added some simple dependency tracking. I've only been able to test the changes on Unix, and expect Guido will soon test it with MSVC. I'd appreciate it if people with other affected compilers (Borland, Cygwin, EMX) could test it. Jeremy

4 3