search

nipreps / fmriprep

fMRIPrep is a robust and easy-to-use pipeline for preprocessing of diverse fMRI data. The transparent workflow dispenses of manual intervention, thereby ensuring the reproducibility of the results.
https://fmriprep.org
Apache License 2.0
637 stars 295 forks source link

Make command line arguments consistent #414

Closed chrisgorgo closed 7 years ago

chrisgorgo commented 7 years ago

Some arguments use underscores --participant_label and some use hyphens --task-id this can be confusing. We should make them all use one schema (preferably underscores unless we want to change the BIDS Apps schema).

oesteban commented 7 years ago

GNU options prefer hyphens (https://www.gnu.org/prep/standards/standards.html#Option-Table)

I personally find hyphens more readable (particularly with long command lines, which happens often with docker/singularity), but I don't have a strong opinion about this.

chrisgorgo commented 7 years ago

I agree. I wish we set this differently in BIDS apps (which is my fault). Not sure how hoard will it be to change it.

On Sat, Mar 25, 2017 at 5:43 PM, Oscar Esteban notifications@github.com wrote:

GNU options prefer hyphens (https://www.gnu.org/prep/ standards/standards.html#Option-Table)

I personally find hyphens more readable (particularly with long command lines, which happens often with docker/singularity), but I don't have a strong opinion about this.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/poldracklab/fmriprep/issues/414#issuecomment-289249873, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOkpyiiO5Rvnoqoc5SHkWOSnyuiwA_Sks5rpbSigaJpZM4MpQv3 .

effigies commented 7 years ago

The only things using _ are --participant_label, --n_cpus, and --mem_mb, the latter two of which I think are BIDS Apps requirements?

Would it be hard to update the BIDS Apps spec to permit hyphens wherever there are underscores, but require required options from previous versions of the spec need to be respected, if not advertised? That is, it would allow us to use --participant-label and show it in our help, but require us to accept --participant_label as a semantically equivalent flag?

The alternative seems to be to standardize on _, which would be a small amount of work for us, but cause users to have to rewrite command lines.

I feel like changing the BIDS Apps spec would be minimally disruptive to users.

oesteban commented 7 years ago

For mriqc I accept both --participant-label and --participant_label and did not have any problems so far. I guess we can have the _ versions for a while, and deprecate when BIDS Apps spec deprecates them.