Closed nilsoberg closed 2 months ago
My comment was about continuing to develop the scripts/workflows as if they will be used by people, not just run as a backend to the site. For now I agree that writing good documentation is more important and this does not need to be merged.
The rationale for this issue/PR is for option clarity. In new scripts I've been changing options to indicate if an option is a file or an input or output file, and I thought I could make this retroactive since the number of options will become more complicated over time as import features get added. For example, in some scripts it may be beneficial to designate options as being a file (e.g.
--optionX-file
) or input and output if there are both (e.g.--optionY-input-file
and--optionY-output-file
).However, in retrospect I think this issue/PR shouldn't ever been opened and I'm inclined to reject the PR. This could be a case where the Keep It Short and Simple principle might be applied.
--help
, documentation, POD, or reading a script should be sufficient. However, I am open to keeping the PR but changing the options to--fasta-file
(instead of--user-fasta-file
) -- assuming that was what you were meaning.