Currently you are able to create a version fork with law run Task2 --version version2 --Task1-version version1.
This allows you to have the previous files under the name version1 but create a fork where outputs will be version2.
This is nice, but gets messy later as the structure becomes confusing. An example of creating a version fork for bbWW at HistTupleProducer
law run HistTupleProducerTask --version v2605a_noDYCorrs --period Run3_2023 --AnaTupleFileListTask-version v2605a --AnalysisCacheTask-version v2605a --AnaTupleMergeTask-version v2605a --AnalysisCacheAggregationTask-version v2605a --branches 0 --workflow local --remove-output 0,a,y
In this case, HistTupleProducer depends on AnaTupleFileList, AnaTupleMerge, AnalysisCache (HME and DNN are both handled by one class), and AnalysisCacheAggregation. Each one must be listed individually.
Suggestion is to allow a 'get all dependencies under this version' arg.
law run HistTupleProducerTask --version v2605a_noDYCorrs --period Run3_2023 --dependencies-version v2605a --branches 0 --workflow local --remove-output 0,a,y
Currently you are able to create a version fork with
law run Task2 --version version2 --Task1-version version1.This allows you to have the previous files under the name
version1but create a fork where outputs will beversion2.This is nice, but gets messy later as the structure becomes confusing. An example of creating a version fork for bbWW at HistTupleProducer
In this case, HistTupleProducer depends on AnaTupleFileList, AnaTupleMerge, AnalysisCache (HME and DNN are both handled by one class), and AnalysisCacheAggregation. Each one must be listed individually.
Suggestion is to allow a 'get all dependencies under this version' arg.