RE: [Distutils] test suite support
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: "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
participants (2)
-
Moore, Paul
-
Thomas Heller