[Bioperl-l] Bioperl-run Wrappers

[Ben Bimber]

Jason,

thanks for the reply - i will look into that more, but that looks
roughly comparable to what i tried to do.

the one comment i have is that "Returns : float or undef" may or may
not be the right thing.  i forget which forum i saw this in, but
relatively recently there was a similar discussion about whether
version was a string or numeric.  it happened because some tool
reported its version as "1.3b".  one could argue that this is the
tool's fault and a version is always numeric, but it should be noted
that sometimes it isnt reported as such.

-Ben




On Fri, Feb 4, 2011 at 4:03 PM, Jason Stajich <jason.stajich at gmail.com> wrote:
> There is such a method in the Wrapper interface - it is implemented for
> tools (exe) that support outputting the version in some way. e.g. here is
> implementation for infernal (Bio::Tools::Run::Infernal)
>
> =head2  version
>
>  Title   : version
>  Usage   : $v = $prog->version();
>  Function: Determine the version number of the program (uses cmsearch)
>  Example :
>  Returns : float or undef
>  Args    : none
>
> =cut
>
> sub version {
>    my ($self) = @_;
>    return unless $self->executable;
>    my $exe = $self->executable;
>    my $string = `$exe -h 2>&1`;
>    my $v;
>    if ($string =~ m{Infernal\s([\d.]+)}) {
>        $v = $1;
>        $self->deprecated(-message => "Only Infernal 1.0 and above is
> supported.",
>                          -version => 1.006001) if $v < 1;
>    }
>    return $self->{'_progversion'} = $v || undef;
> }
>
>
>
> Ben Bimber wrote:
>>
>> Hi Chris,
>>
>> I actually was referring to the software version of the executable
>> itself, not the perl code.  for example, I added something like this
>> to a mosaik wrapper I made:
>>
>> sub version {
>>        my $self = shift;
>>        my ($out, $err);
>>        IPC::Run::run([$self->executable, '-h'], '>', \$out, '2>', \$err);
>>        my @out = split("\n", $out);
>>        my $version = join(';', grep( /^Mosaik/i, @out));
>>        $version =~ m/^.*0m ([\d\.]*)\b/i;
>>        return "Mosaik Version: $1\n";
>>
>> }
>>
>> It runs the executable, parses the output (which is specific to mosaik
>> in this case) and returns it.  I had an issue with a tool version
>> recently, so I decided it was probably a good idea to start recording
>> them with pipelines.  In hindsight version() is probably the wrong
>> name since it's confusing with perl's VERSION, but maybe exe_version()
>> or something makes sense.  I would personally find it useful if there
>> were a standard, but optional method across BioPerl wrappers to do
>> this sort of thing.  implementing it would be optional per wrapper.
>> all it would really need to do it return a string.
>>
>> -Ben
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Feb 4, 2011 at 3:19 PM, Chris Fields<cjfields at illinois.edu>
>>  wrote:
>>>
>>> On Jan 28, 2011, at 12:18 PM, Ben Bimber wrote:
>>>
>>>> Hello,
>>>>
>>>> I'm using CommandExts to wrap a number of tools.  In a pipeline I was
>>>> looking to make the tools log their current version.  I realized that
>>>> instead of using run() in a unique way for each tool, perhaps there
>>>> should be a consistent method that gets called and returns a version
>>>> string.  because obtaining this version string is specific to the
>>>> tool, perhaps each wrapper could provide a version() method that runs
>>>> the appropriate command on the executable, parses, then returns some
>>>> string.  has something like this been discussed?  have others already
>>>> solved this?
>>>>
>>>> Thanks,
>>>> Ben
>>>
>>> (apologies for the late response, maybe you worked it out?)
>>>
>>> If you mean a version string for the wrapped tool, there is a
>>> Bio::Tools::Run::WrapperBase method called version() I believe (not
>>> implemented for obvious reasons, but implemented by each wrapper as needed).
>>>  If you want a specific version of the module (say, an API version) you may
>>> want to assign $VERSION or create a new global ($API_VERSION, perhaps) in
>>> case it conflicts with the BioPerl core version.
>>>
>>> chris
>>>
>>>
>>>
>>
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>
> --
> Jason Stajich
>
>
>