[ENH] Formalize presence of optional logs/ folder #1962
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It is quite often desired to store logs, e.g. simply stdout/stderr from invocation of BIDS converters or other tools which were used to produce/change content in current BIDS datasset. They quite often provide ultimate provenance information to troubleshoot odd or incorrect results. But researchers, in my personal opinion, undervalue logs! But hinting them on "standard" location for them, I think we could inspire more of relevant to dataset provenance metadata being collected and shared. Dangers: might leak sensitive metadata, so may be wording should be adjusted to mention that they should be inspected/sensored. Shameless plug: consider using con-duct (https://github.com/con/duct) for your "logging needs". Note that I think that ideally the `logs/` should not include "derivative" data, such as e.g. output of `bids-validator`. Those outputs should go under `derivatives/bids-validator-{version}/output.json` or alike. (It might be the only reasonable "derivative" to recommend bundling with any "raw" or derived BIDS dataset).
yarikoptic
requested review from
erdalkaraca and
DimitriPapadopoulos
as code owners
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1962 +/- ##
=======================================
Coverage 86.87% 86.87%
=======================================
Files 16 16
Lines 1410 1410
=======================================
Hits 1225 1225
Misses 185 185 ☔ View full report in Codecov by Sentry. |
yarikoptic
added
opinions wanted
effigies
approved these changes
Nov 11, 2024
There was a problem hiding this comment.
I'm fine with this. Up to now I probably would put them under code/ but that's not really the right place.
This is, IMO low-priority to standardize, since the logs themselves are not standardized, so this doesn't make them substantially more legible to tooling. But it doesn't harm anything that I can see and it's unlikely to have another use.
Co-authored-by: Chris Markiewicz <effigies@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It is quite often desired to store logs, e.g. simply stdout/stderr from invocation of BIDS converters or other tools which were used to produce/change content in current BIDS datasset. They quite often provide ultimate provenance information to troubleshoot odd or incorrect results. But researchers, in my personal opinion, undervalue logs! But hinting them on "standard" location for them, I think we could inspire more of relevant to dataset provenance metadata being collected and shared.
TODOs:
?Danger: might leak sensitive metadata, so may be wording should be adjusted to mention that they should be inspected/sensored? WDYT?I think it is fine/assumedShameless plug: consider using con-duct (https://github.com/con/duct) for your "logging needs".
Note that I think that ideally the
logs/should not include "derivative" data, such as e.g. output ofbids-validator. Those outputs should go underderivatives/bids-validator-{version}/output.jsonor alike. (It might be the only reasonable "derivative" to recommend bundling with any "raw" or derived BIDS dataset).