Don't contact myMdC to get run creation time
Description
The code to get the creation time of a run preferred getting it from myMdC if possible, with a fallback to looking at the files. Talking to an external service is a problem for reproducibility - when you re-run it, the response from the external service might be different, the API you're using might have changed, or you might be running it without the credentials (configured per user) to access myMdC. The fallback mitigates this, but might give a different answer from myMdC.
It's also easier for people to try running the calibration code if there's no need to configure an Oauth token for myMdC.
Files from 2020 onwards appear to have the INDEX/timestamp dataset; Luis has told me that the start time in myMdC is taken from the timestamp of the first train, so this should reliably give us the same answer. For older files, it falls back to finding the earliest modification time of the .h5 files in the directory.
How Has This Been Tested?
The functions this uses were already used as fallbacks, and are covered by tests.
Types of changes
- New feature (non-breaking change which adds functionality)
Checklist:
- My code follows the code style of this project.
Reviewers
Merge request reports
Activity
Could we force the reproducibility package to not use myMDC by withholding the tokens from it? Then it would at least use whatever fallback the source was using at the time.
Edited by Philipp Schmidt
I'm not exactly sure what you mean with that.
This is part of the code that runs inside the notebooks, so the machinery running the notebooks doesn't specifically know about it. We could certainly come up with a way for the machinery to block this specific mechanism, but I'm not sure what that would achieve.
If we block this only while trying to reproduce a calibration, then we're forcing it to take a different code path and potentially get a different result to what originally happened. To be consistent, we'd want to block it for the original run as well - but then we may as well just remove the mechanism entirely.
If we block this only while trying to reproduce a calibration, then we're forcing it to take a different code path and potentially get a different result to what originally happened.
I did not consider that. I'm probably slightly frustrated all these small things start showing up after we cracked the big questions about reproducibility.
-
'fraid so. We've got the machinery in place, but actually making the code behave consistently is a fair bit of work.
In fairness, this one probably doesn't matter that much. The creation time should be the same whether it comes from myMdC or the files, and if we've saved the chosen constans, we shouldn't even need to use the calibration time. It's just a potential loose end that I wanted to clean up.
changed milestone to %3.7.0
mentioned in commit 0ccaffac
