Create/populate .bidsignore with .git (if datalad mode?) and .heudiconv

[yarikoptic]

It seems that many BIDS tools might look outside of the standardized by BIDS locations, and thus end up in .git or in .heudiconv and then complain about their hard destiny. (e.g. nipreps/fmriprep#2426 but user followed up with complaints about .heudiconv after datalad clean).

To prevent that from happening I think we should just populate in bids mode .bidsignore with all those non-interesting locations:

.git
.datalad
.heudiconv

where no bids tool should look under... or may be it should just become .*? unfortunately .bidsignore is not part of the BIDS standard (see discussion bids-standard/bids-specification#131) so the "utility" from it might be limited...

[effigies]

Yes, .bidsignore is specifically a validator solution. The problem is that ignoring could either mean "ignore file" or "ignore errors related to file". In the validator it's the same, in other tools, it's ambiguous.

It might make sense to put .heudiconv into .gitignore, so that it never enters the dataset, though perhaps that's also not desirable.

[mgxd]

alternatively, we could stick .heudiconv/ into <bids-root>/code in the case of BIDS conversions

[effigies]

Is it code or provenance?

[mgxd]

I think it falls in line with the definition of what it's intended for the spec, specifically

conversion from the format of the source data to the BIDS format

[effigies]

Seems reasonable, then. Found one in my cache to look at, and it looks like it may also potentially include private data, which is not ideal for publication.

[yarikoptic]

It might make sense to put .heudiconv into .gitignore, so that it never enters the dataset, though perhaps that's also not desirable.

ATM I do keep that content under git in the same repo or under submodule. Adding it to .gitignore would complicate managing it. Indeed, those could leak protected data, thus should be added under git-annex and not shared.

Is it code or provenance?

both. .py copies of heuristic are "code". .txt etc -- pure provenance to establish provenance of the conversion to e.g. later locate that data on a server elsewhere.