Various events related to the Catalog- and Distutils-SIG happened at IPC9 this past week. To summarize them: * Sean Reifschneider demonstrated swalow during the Lightning Talks session and got a favorable reaction from the attendees. * Packaging was discussed at Paul Prescod's BoF session, and some decisions were made there. (More about that below...) * On Developer's Day, Moshe turned over half of his "Batteries Included" session to me for catalog discussion, and a few more items were added to the task list. So, here's the plan of action: 1) For 2.1final, change the Distutils sdist command to construct a text file containing the metadata for a package. Exactly *what* metadata to collect was left open for subsequent discussion on the Catalog-SIG. (Amos has a patch to implement this that I'll look at when I can.) This is the only thing to be done in time for 2.1, so it's the only really pressing task. 2) Once that metadata support is there, someone can start running an experimental swalow server and begin adding to its database. If Python 2.2 comes along in 6-12 months, that should be enough time to have an idea of what should go into 2.2 to support it. 3) Other Distutils changes would be to design and create a package database, and implement an uninstall command. The 'sdist' command would also grow an --upload or --register option that would automatically submit the package to the catalog (but first we'd need to finalize how that should be done). I'll make a separate post to start the metadata discussion. --amk
Andrew Kuchling wrote:
1) For 2.1final, change the Distutils sdist command to construct a text file containing the metadata for a package. Exactly *what* metadata to collect was left open for subsequent discussion on the Catalog-SIG. (Amos has a patch to implement this that I'll look at when I can.)
This is the only thing to be done in time for 2.1, so it's the only really pressing task.
2) Once that metadata support is there, someone can start running an experimental swalow server and begin adding to its database. If Python 2.2 comes along in 6-12 months, that should be enough time to have an idea of what should go into 2.2 to support it.
3) Other Distutils changes would be to design and create a package database, and implement an uninstall command. The 'sdist' command would also grow an --upload or --register option that would automatically submit the package to the catalog (but first we'd need to finalize how that should be done).
Note that we already decided on the name of the uninstall command at the conference: "uninstall". Package developers can use this command name to implement this feature in a forward compatible way. Another point I'd like to raise is that of providing a generic "test" command. Most packages provide regression tests which allow to quickly find out where problems might be hiding. There is currently no support in distutils to run these tests. Could we make a similar decision on the name of the command (before actually adding support for it to distutils), so that package authors can start coding their own implementation now ?! -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
On Wed, Mar 21, 2001 at 12:19:04PM +0100, M.-A. Lemburg wrote:
Could we make a similar decision on the name of the command (before actually adding support for it to distutils), so that package authors can start coding their own implementation now ?!
"test" seems the most obvious command name, so let's choose that. (Which reminds me... they don't seem to have added PyUnit to the core yet...) --amk
On Wed, Mar 21, 2001 at 12:31:41PM -0500, Andrew Kuchling wrote:
On Wed, Mar 21, 2001 at 12:19:04PM +0100, M.-A. Lemburg wrote:
Could we make a similar decision on the name of the command (before actually adding support for it to distutils), so that package authors can start coding their own implementation now ?!
"test" seems the most obvious command name, so let's choose that. (Which reminds me... they don't seem to have added PyUnit to the core yet...)
Along with the name, I think that it'll have to have a default stub which
does an "exit(0)" (the default test succeeds) so that the lack of a test
doesn't show up the same as a test failure.
Sean
--
"Having computers is a lot like having kids, except it's not as much of a
problem if they die while you're away." -- Sean Reifschneider, 1997
Sean Reifschneider, Inimitably Superfluous
On Sat, Mar 24, 2001 at 01:14:46AM -0700, Sean Reifschneider wrote:
Along with the name, I think that it'll have to have a default stub which does an "exit(0)" (the default test succeeds) so that the lack of a test doesn't show up the same as a test failure.
An open question: what should the 'test' command do? We could adopt some convention to automatically locate test scripts automatically (all files matching test/*.py, for example), with a tests=['dir/test1.py', dir/test2.py'] override to explicitly list test scripts and ignore the convention. Next, what would it do with the test scripts? In 2.1b2, test.test_support.run_unittest() raises TestFailed when a test suite fails. Would it be sufficient to execfile() all the test scripts, note which ones raise TestFailed, and print a list of failing tests (which would come after the output of individual test scripts). --amk
Andrew Kuchling wrote:
On Sat, Mar 24, 2001 at 01:14:46AM -0700, Sean Reifschneider wrote:
Along with the name, I think that it'll have to have a default stub which does an "exit(0)" (the default test succeeds) so that the lack of a test doesn't show up the same as a test failure.
An open question: what should the 'test' command do? We could adopt some convention to automatically locate test scripts automatically (all files matching test/*.py, for example), with a tests=['dir/test1.py', dir/test2.py'] override to explicitly list test scripts and ignore the convention.
I would prefer to have an option which then tells distutils which files should be run a regression test, e.g. tests=['a.py','b.py'].
Next, what would it do with the test scripts? In 2.1b2, test.test_support.run_unittest() raises TestFailed when a test suite fails. Would it be sufficient to execfile() all the test scripts, note which ones raise TestFailed, and print a list of failing tests (which would come after the output of individual test scripts).
Please don't make any assumptions about the framework behind the test suites -- not everyone is going to use pyunit for this... I'd suggest to simply run the scripts defined in the tests parameter and look at the resulting shell return code (0 - success; everything else: failure). -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/
I would prefer to have an option which then tells distutils which files should be run a regression test, e.g. tests=['a.py','b.py'].
How about tests = [('testDir1', ['a.py','b.py']), ('testDir2', ['c.py','d.py', 'e.py']) ] And it would then change into the specified test directory before running the test scripts found there, and more than one group could be specified.
Please don't make any assumptions about the framework behind the test suites -- not everyone is going to use pyunit for this...
I'd suggest to simply run the scripts defined in the tests parameter and look at the resulting shell return code (0 - success; everything else: failure).
I agree. -- Robin Dunn Software Craftsman robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython!
On Wed, Mar 28, 2001 at 08:45:11AM -0800, Robin Dunn wrote:
tests = [('testDir1', ['a.py','b.py']), ('testDir2', ['c.py','d.py', 'e.py']) ]
I like having the computer do things so that I don't have to. How about allowing glob patterns in the above, so it could be ('testDir1', ['test_*.py']).
I'd suggest to simply run the scripts defined in the tests parameter and look at the resulting shell return code (0 - success; everything else: failure).
I agree.
Another reason to do this: running everything in one interpreter instance could conceal weird bugs where data structures aren't being initialized properly in a single test, but because previous modules did the initialization, the code works. So forking is clearly the right thing to do. Should I begin writing a PEP on this for 2.2? --amk
Should I begin writing a PEP on this for 2.2?
What do you mean: Jump from 1.0.2pre to 2.2 ;-) ? Seriously: Won't there be separate distutils releases any more? Will distutils completely accept python's development practices? PEPs and all? In this case it seems I would also have to write a PEP for uninstallation (wininst and distutils in general). Thomas
On Thu, Mar 29, 2001 at 06:16:16PM +0200, Thomas Heller wrote:
Should I begin writing a PEP on this for 2.2?
What do you mean: Jump from 1.0.2pre to 2.2 ;-) ? Won't there be separate distutils releases any more?
I mean so that it gets into Python 2.2; Distutils releases will continue, at least until Python 1.5.2 is dead and gone, which seems to be about 2 years away.
Will distutils completely accept python's development practices? PEPs and all? In this case it seems I would also have to write a PEP for uninstallation (wininst and distutils in general).
That's actually a good question. The 'test' command will raise some issues, but it shouldn't be too complicated, and a PEP may be overkill. I'm actually happy just discussing things, doing a first implementation, and then poking at the code, but would like to know what the rest of the SIG's readers think. For example, I'm not sure what a bdist_wininst PEP would have accomplished, and don't see the need to write one now. --amk
On Wed, Mar 28, 2001 at 08:45:11AM -0800, Robin Dunn wrote:
tests = [('testDir1', ['a.py','b.py']), ('testDir2', ['c.py','d.py', 'e.py']) ]
I like having the computer do things so that I don't have to. How about allowing glob patterns in the above, so it could be ('testDir1', ['test_*.py']).
Yes. -- Robin Dunn Software Craftsman robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython!
participants (5)
-
Andrew Kuchling -
M.-A. Lemburg -
Robin Dunn -
Sean Reifschneider -
Thomas Heller