Not issue, just notification: BIDS CLI

[TheChymera]

I recently wrote a (very very small) CLI wrapper for our bidsschematools (BST) package. Not sure if any of you also find it useful, but I certainly find it convenient. DANDI ofc also bundles our mini-validator and has CLI, but really it's a pretty big package.

Might be a useful place to put additional functionality into, without burdening the BST code and its XS validator, which it would be pretty cool if we could keep XS :)

Here's a brief demo:

https://ppb.chymera.eu/e59c6a.mp4

@yarikoptic

[sappelhoff]

thanks! btw, is "XS" for "extra small" or what is it?

[yarikoptic]

do you foresee implementing some custom functionality which would not be in bidsschematools? if not -- the best would be just to provide CLI by bidsschematools itself. It would simplify distribution and maintenance (one package instead of too) especially currently whenever bidsschematools is still in such rapid development phase with changing API.

FWIW `bst` CLI is already taken but by a quite specialized tools (never heard about it although should look into it) https://buildstream.build/. So could still become `bst validate` and alike

$> apt-file search bst | grep bin/bst
blackbox: /usr/bin/bstyleconvert
buildstream: /usr/bin/bst

FWIW, the dreams of a bids CLI helper are still wet after all these years, and we are missing very basic files manipulation helper (such as e.g. rename sub-X sub-Y) which would properly take care about all dependencies (all the file names, _scans.tsv, participants.tsv, ...). Some refs: bids-standard/pybids#774 bids-standard/bidsutils#6 etc.

With that in mind, I would not make bst to claim to be an ultimate bids CLI but rather specific CLI interfacing to bidsschematools module. Could even be interfaced for starters as buildsschematools/__main__.py so available via python -m buildschematools but not sure if that plays well e.g. with click or argh you chose.

[yarikoptic]

FWIW, if to add to bidsschematools -- please stay away from argh -- seems to be no longer maintained (last commit/release in 2016!!!). click is powerful, easy, and maintained.

[TheChymera]

@sappelhoff

is "XS" for "extra small" or what is it?

Yes, it was the original name for the built-in validator to distinguish it from separate packages which leverage deep dep stacks (including e.g. pandas) or focus on providing graphical functionality.

@yarikoptic

do you foresee implementing some custom functionality which would not be in bidsschematools

Yes, but ideally not too much.

we are missing very basic files manipulation helper

Yes, I also thought about that... however I think it might be best to not reproduce GNU coreutils functionality in BIDS-land. The benefit of leveraging tree structures and paths is that we can rely on rm, cp, mv, ls, and also non-core but equally ubiquitous packages like diff, grep, sed etc. directly. If we try to BIDSify these rather basic commands we might as well be using a database and SQL commands. I'm thinking that easier moving is something that should be given thought in the standard itself i.e. by reducing interdependency of files :) --- though to be fair, git also has coreutils-analog subcommands without becoming too self-absorbed. For the time being we don't have this, and if we ever do, initially I would first consider implementing functions so they can easily be concatenated with mv, cp, etc.

Could even be interfaced for starters as buildsschematools/__main__.py

I would like to keep ancillary functionality out of bidsschematools, because if we do put it in, it will bloat the package, provide more than the stated purpose of reference schema-co-developed parsing logic, and people will correctly argue that in that case it should just be split off --- in which case we just ended up with a pythonic version of bids-validator which may easily diverge from the schema with features needing to be coordinated across repos etc.

please stay away from argh

There is already an issue about that. The issue with click (or why not just vanilla built-in argparse for the sake of light weight and long-term reliability) is that they do not automatically create arguments. In order to reduce coordination issues across the BIDS environment --- particularly in view of current rapid development, as you correctly identified as an important consideration above --- it would really benefit us to have the command line automatically generated based on imported function attributes, such as e.g. the docstring or the signature, which is what argh uses. In any case it works for now, but if you ever come across another auto-parser, let me know in the aforementioned issue. I agree it should be changed at some point and also looked for a while last night, but didn't find much.

[TheChymera]

So apparently we have some built-in CLI things in bidsschematools from @effigies as well.

I wonder whether the best approach would be add CLI bindings for validation in BST, or whether the existing bindings shouldn't be split off.

Any opinions? The main danger we're running here is BST starting to do too many things. I kind of liked the notion that it's just a simple python library which people can build stuff (including CLI bindings) on, and which will likely be fairly well maintained on account of being lightweight...

[sappelhoff]

Any opinions? The main danger we're running here is BST starting to do too many things. I kind of liked the notion that it's just a simple python library which people can build stuff (including CLI bindings) on, and which will likely be fairly well maintained on account of being lightweight...

If this is still of relevance, please open a new, targeted issue for this to discuss (potentially backlinking to this one).

I am closing this announcement now, people who search for it will still find it, and all others will likely not see it anyways, buried on page N in bids-spec issues :-)