Replies: 1 comment
-
|
I've thought about this some more: one thing extra modules may need ready access to is the key arguments parsed from the CLI (input/ouput dir, participant_label, derivatives, etc). |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
There's a couple ideas floating around that are somewhat challenging to incorporate into the snakemake core. These include logging (#184), bids validation (#222),
dataset_description.jsonmanipulation (#154), and possibly others, plus a few utility functions I've thought of but haven't raised yet.I'd like to propose that, for these types of problems, we conceive of a sort of
snakebidsextra (or some more catchy name) that is not directly handled bySnakebidsAppbut is intended to be manually invoked by the developer within therun.py. The implementation of these "extras" would be extremely flexible (functions, classes, etc), although some may benefit from "plugging" intoSnakebidsApp. These extras could be packaged in withsnakebidsor distributed as 3rd party libaries. The main defining feature is that they are used withinrun.py(so callingsnakemakedirectly would skip the extras).Obviously this is not really an "actionable" idea leading to a specific new feature. I more wanted to create a conceptual category we can start sorting feature ideas into. It might even be worth creating some Issue tags to this end.
Beta Was this translation helpful? Give feedback.
All reactions