steve at purkis.ca
Fri Sep 11 10:18:49 BST 2009
On 6 Sep 2009, at 18:16, David E. Wheeler wrote:
> On Sep 6, 2009, at 6:51 AM, Steve Purkis wrote:
>> BTW, what do people think about the dependency on YAML here? I
>> couldn't get YAMLish::Reader to work. It's safely loaded...
> I don't really care for it. I'd prefer something like:
> prove --source pgTAP --pgtap-option dbname=try --pgtap-option
> That way you can use the standard Getopt::Long format for creating
> hashes on the command-line. All you'd have to do is make sure that
> each source handler defines a prefix -- or else just use the last
> part of the source package name in lowercase -- to specify option
> types for Getoptions.
Hmm - I know what you mean. We discussed this one a while ago for the
-P option and got nowhere with it. Personally, I'd like to see
plugins being able to define their own options, but that's another
project altogether. The trouble is you don't know the names of all
potential plugins, so what do you pass to GetOptions()? That's why I
thought the YAML approach was a good compromize - at least it gets
options to the sources.
I'd say it's a choice between the YAML or some similar approach, or
only being able to specify the sources to use (and perhaps configure
them via %ENV - yucky but will work).
>> Suits me fine, though I'd say:
>> * The 1.0 votes should be lowered then so they can be overrided by
>> other plugins in the future. Of course, I didn't set a limit on
>> the max, so it's just syntactic sugar...
> I could see lowering the .pg suffix, but if a user specifies a
> suffix via an option, I think that should be 1.0.
>> Rename Iterator::Stream --> Iterator::Handle?
>> Rename Iterator::Process --> Iterator::Executable?
>> worth doing?
Why? Consistency with the SourceHandlers. But I think there's not
much point, so lets scratch that one off the list.
>> Process iterator should be really easy to use
>> is there anything to do here?
> I think it's simple enough, based on my experience with the pgTAP
> source handler.
Good, less work :)
>> Before we merge back to trunk we should definitely do these:
>> Test across all platforms
>> Code review
>> Documentation review
>> Update Changes
> I'll try to review stuff this week and test on the platforms I have
> access to (Ubuntu and OS X). Some Win32 testing would be most useful.
Thanks, and agreed re: Win32. Any volunteers?
>> But I'm not in a position to do the first, and it's not appropriate
>> for me to do the others.
> I think you should update Changes, frankly.
Happy to, assuming Andy's ok with that. But I'll wait until it gets
merged back into trunk.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tapx-dev