[emboss-dev] Commandline changes in EMBOSS applications
Peter Rice
pmr at ebi.ac.uk
Thu Sep 29 14:43:04 UTC 2011
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
EMBOSS Team
More information about the emboss-dev
mailing list