propose build_dir in data.yaml as only relevant for GitData(StaticData) #27
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.
Was considering putting build_dir as a top-level option, e.g. in config.yaml, and then pass it through the DatatStore instantiation as argument alongside data_dir. However, this requires lots of additions of build_dir=None as keyword argument in multiple levels of class instantiations. For example:
and then further above:
and also
so that we can put in nodes.py or equivalent:
And ultimately is the build_dir the same for all git repos?
My understanding is that build_dir is only relevant for GitData(StaticData) class. Perhaps it's better to provide it with the static_data options?
The price is potential duplication of paths defined in config.yaml and data.yaml if non-standard, i.e. other than $TMPDIR/build.
I leave it to the developers to choose what they prefer as best aligned with the wellies spirit. I provide both options in two different commits.