[emboss-dev] Commandline changes in EMBOSS applications

Peter Cock p.j.a.cock at googlemail.com
Thu Sep 29 15:03:08 UTC 2011

On Thu, Sep 29, 2011 at 3:43 PM, Peter Rice <pmr at ebi.ac.uk> wrote:
> A question for our developer community...
> I am working through the GALAXY wrappers for EMBOSS applications. GALAXY has
> a very clean way to define command line applications which is close to
> EMBOSS's ACD definitions, so most applications are easy to define.
> I have problems where the default values in the ACD file depend on other
> values. Two examples from prettyplot illustrate the problem. In both cases,
> the current GALAXY definitions ignore these qualifiers.
>  integer: residuesperline [
>    default: "50"
>    information: "Number of residues to be displayed on each
>                  line"
>  ]
>  integer: resbreak [
>    information: "Residues before a space"
>    default: "$(residuesperline)"
>    expected: "Same as -residuesperline to give no breaks"
>  ]
> The second qualifier defaults to the value of the first. GALAXY is unable to
> interpret this. It could be defined with a default of "50" for GALAXY, but I
> would prefer to remove this qualifier and add a new one "-blocksperline"
> with a default of 1. In this way the dependency disappears, and the results
> are cleaner.
> The second value is a calculation from sequence properties:
>  float: plurality [
>    information: "Plurality check value (totweight/2)"
>    default: "@( $(sequences.totweight) / 2)"
>    expected: "Half the total sequence weighting"
>  ]
> This has a long history, back to the EGCG version of prettyplot where the
> command line options were extensions of a GCG program. The "weight" is by
> default 1.0 per sequence, but GCG format had a way to adjust weights in the
> input file. Plurality is nice in that it allows a definition of how many of
> the sequences should match.
> In this case, it seems easier to ignore the weight-based value and instead
> to define -percent 50.0 then multiple the total weight (or number of
> sequences) by 0.50 and get the same results.
> I am a little nervous about removing command line options because of the
> risk of breaking some interfaces.
> So:
> 1. Should I go ahead and add the new options?
> 2. Do I remove the old options so old wrappers, scripts, etc. break with
> "unknown qualifier -plurality"
> 3. Or, do we keep the old options, declare them obsolete, object to their
> use but keep going
> As option 3 would also complicate life for wrappers - anyone making new
> wrappers would most probably include the obsolete options - I prefer 1+2 but
> I would appreciate some feedback.
> regards,
> Peter Rice

Hi Peter R,

In theory you can use an optional integer parameter in Galaxy,
with an empty default,  meaning the user doesn't have to put in
a value. You can then check this in the tool wrapper's XML
<command> tag with Cheetah syntax to decide if you add
the -switch value to the command string (with the user's value),
or not (to get the EMBOSS default).

Perhaps I have misunderstood, but I think it is supported in
Galaxy although probably quite fiddly.

Peter C.

More information about the emboss-dev mailing list