Should custom_paths be resolved relative to bids_dir

[pvandyken]

I was recently trying the custom_paths feature of Snakebids. In my first attempt, I assumed that the custom_path I provided would be appended to whatever path I provided to bids_dir in the generate_inputs() function. So the full path would be /[bids_dir]/[custom_path]. This was not the case, of course, and so my workflow didn't work and I updated it accordingly. Should this behaviour be updated to meet my original intuition?

First, I should acknowledge that we're discussing a breaking change, so the outcome of the discussion could be that the change would be nice but is not worthwhile enough for the breaks it would create.

One argument against it may be that it would limit the flexibility of custom_path. For example, currently you may have a bids input living in /path/to/bids, and a completely different dataset with custom paths in /path/of/completely/different/data/with/custom/paths. Under the current circumstances, you can inform generate_inputs() of both datasets without issue. If the behaviour was changed, the custom path would have to be defined relative to the bids input (e.g. ../of/completely/**).

To this I would respond that it's actually preferable to treat these different datasets separately, including separate definitions in config and separate generate_inputs() calls. So you move from this structure:

pybids_inputs:
  bold:
    filters: [...]
    wildcards: [...]
  custom_data:
    custom_path: /path/of/completely/different/data/**

to:

main_data_name:
  bold:
    filters: [...]
    wildcards: [...]

secondary_data_name:
  custom_data:
    custom_path: data/**

with corresponding calls to generate_inputs()

main = generate_inputs("/path/to/bids", config["main_data_name"])
secondary = generate_inputs("/path/of/completely/different", config["secondary_data_name"])

It's a paradigm shift from the current treatment, but I think it offers more flexibility. Keep in mind that in real code, the bids_dir argument of generate_inputs() would not be literally defined as above, but would be taken from config (e.g. config["bids_dir"]), which in turn would come from the CLI. The above convention would allow apps to consume multiple datasets stored in completely different locations with ease.

Again, I realize this would be a breaking change, so I'm not completely sold on the idea, but I'd be interested in thoughts.

[akhanf]

This option was designed as a way to deal with data that is not in bids format, or in a different bids dataset for whatever reason (ie for some reason that the app developer couldn't be aware of). If the app is really meant to act on multiple bids datasets then i agree that multiple bids datasets should be parsed, instead of instructing the user to use --path-* options. I think the --path-* options really should only be reserved for non-bids compatibility. When I use the path option myself, I set the bids directory to '-' to ignore bids parsing altogether.

One non-breaking suggestion to make the abs/rel path more intuitive is to add a --rel-path* set of options that assume relative to bids?

[pvandyken]

As a matter of fact, I had completely forgotten about custom_path's association with --path-*. Considered in that light, the design makes much more sense.

For my application, I was using custom_path directly as part of an app to rename a dataset (TOPSY) to be bids compatible. This is why I had "multiple datasets". The data was being pooled from a few different places (pipelines, in my case).

I agree with the comments on --path-*: nothing should change there. So perhaps a new question is: it generally useful to have a custom_paths like attribute within pybids_inputs that can be hard coded into the config and does not have any attachment to --path-*. I can see utility in interfacing with non-bids-compliant pipelines like FSL etc.