I updated my distutils from cvs and installed them. Now, when I try to
running build_ext Traceback (innermost last): File "setup.py", line 69, in ? ext_modules = [ File "/usr/lib/python1.5/site-packages/distutils/core.py", line 98, in setup dist.run_commands () File "/usr/lib/python1.5/site-packages/distutils/core.py", line 533, in run_co mmands self.run_command (cmd) File "/usr/lib/python1.5/site-packages/distutils/core.py", line 582, in run_co mmand cmd_obj.run () File "/usr/lib/python1.5/site-packages/distutils/command/install.py", line 364 , in run self.run_peer ('build') File "/usr/lib/python1.5/site-packages/distutils/core.py", line 899, in run_pe er self.distribution.run_command (command) File "/usr/lib/python1.5/site-packages/distutils/core.py", line 582, in run_co mmand cmd_obj.run () File "/usr/lib/python1.5/site-packages/distutils/command/build.py", line 95, i n run self.run_peer ('build_ext') File "/usr/lib/python1.5/site-packages/distutils/core.py", line 899, in run_pe er self.distribution.run_command (command) File "/usr/lib/python1.5/site-packages/distutils/core.py", line 582, in run_co mmand cmd_obj.run () File "/usr/lib/python1.5/site-packages/distutils/command/build_ext.py", line 1 92, in run self.build_extensions ()
cvs diff -r1.25 build_ext.py shows (among other differences):
# Now actually compile and link everything.
Restoring the old version of this line seems to fix the problem.
Not to be picky, but I'd certainly appreciate better regression testing on distutils, so these trival errors don't occur.
Would you consider tagging CVS revisions for additional sub-releases, like Distutils_0_1_3a, so we'd know what it likely to be stable? As it is, I think I'll have to save a working copy of distutils, before I update from CVS.
--
Joe VanAndel
National Center for Atmospheric Research
http://www.atd.ucar.edu/~vanandel/
Internet: vanandel@ucar.edu
On 30 March 2000, Joe Van Andel said:
I updated my distutils from cvs and installed them. Now, when I try to build my application, I get: [...] "/usr/lib/python1.5/site-packages/distutils/command/build_ext.py", line 1 92, in run self.build_extensions () TypeError: not enough arguments; expected 2, got 1
Arghh! Sorry about that: sloppy and inexcusable. Somebody slap me with a wet noodle. Fixed in CVS now.
Not to be picky, but I'd certainly appreciate better regression testing on distutils, so these trival errors don't occur.
That's a completely fair complaint, and one that I hope to start addressing Real Soon Now with a proper test suite. However, right now I'm smack dab in the middle of adding the "bdist" command with the ability to create a "dumb" binary distribution -- a tarball or zip file that you unpack in $prefix or $exec_prefix to "install" a module distribution. (This is a stepping stone on the way to creating a "smart" binary distribution, like an RPM or Wise installed for Windows.)
Adding support for this has meant revisiting a lot of stable code, and taking advantage of the revisiting to refactor, rethink, and otherwise raise hell. Long term, this is a good thing, but in the short term, the lack of a test suite makes it a wee bit dangerous -- eg. I risk causing stupid breakage in the CVS tree that brave adventurers like you might stumble upon.
This particular bit of breakage was really stupid, and there's no need for a test suite to catch it: I should have just gone and done a quick build of NumPy or PIL to make sure it was still working. I didn't, and I feel (and look) stupid. Sorry again.
However, when you follow the CVS tree day-to-day, you've got to expect some breakage. I really appreciate the fact that you and a few other folks are following the CVS day-to-day, and I apologize for wasting your time with trivial breakage like this. I'll try to only check in real serious breakage in the future, to give you guys something to sink your teeth into. >grin<
Would you consider tagging CVS revisions for additional sub-releases, like Distutils_0_1_3a, so we'd know what it likely to be stable? As it is, I think I'll have to save a working copy of distutils, before I update from CVS.
Hmmm... that's an idea. I think I prefer the dated snapshot approach, though. I got lazy there because a number of people told me it wasn't really necessary, but I think it might be after all. A dated snapshot just says, "Here, the code was fairly stable and seemed to be working when I made this" -- which I think is what you want. I have explicitly not tagged the tree when making a snapshot, and I have deleted old snapshots -- that's to remind myself (and anyone else who cares) that these are not releases.
So I probably should have made a snapshot before I started breaking things to support the "bdist" command -- too late now, unless I indulge in some CVS-sponsored time travel. I will make a snapshot when the create-a-dumb-binary-distribution stuff is working. It's entirely possible that that snapshot will be the same as what's included in the snapshot Guido will create soon (tomorrow?) called "Python 1.6 alpha1". ;-)
Greg
--
Greg Ward - software developer gward@cnri.reston.va.us
Corporation for National Research Initiatives
1895 Preston White Drive voice: +1-703-620-8990
Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913