Metadata: Add qcodes version, git status, git diff and things

[MerlinSmiles]

There are a few points we should save for the metadata:

For qcodes

• Save qcodes version
• Save current git hash
• Save current git branch
• Save git diff if there are changes in the branch (this should be limited to not go crazy on data, notebooks in branches...)

Then there it should be encouraged that a user has all working scripts and stuff in a git repo, and for that one we should save the same information station.add_repo('./scripts')

Then there is the situation where qcodes is a package and installed on a system without git, we need to cover that too, I guess only saving qcodes version then it ok.

I'm not a git genius, which is why it didn't come with the metadata. How should we do this exactly?

~/g/Qcodes git:feature/pyqtgraph_improvements ❯❯❯ git describe --all --dirty --long
heads/feature/pyqtgraph_improvements-0-gb269d73-dirty

~/g/Qcodes git:feature/pyqtgraph_improvements ❯❯❯ git rev-parse  HEAD
b0485b7c5e8448ac5107a43ff05eb730114c284c

~/g/Qcodes git:feature/pyqtgraph_improvements ❯❯❯ git rev-parse --abbrev-ref HEAD
feature/pyqtgraph_improvements

[giulioungaretti]

that's indeed a great idea, but imho totally not v0.1 :D

[alexcjohnson]

If we want to be really fancy and complete, we can look at sys.modules, figure out which ones are in git repos, and get this info for all of those. Then for those that are not in repos, just record their versions, if any.

We can omit standard lib (we should record python version) but including versions of other dependencies could be really handy for debugging. And then we'll know if any code was used that's not under any sort of version control (and if it's short enough we can record the whole friggin module in metadata!)

[giulioungaretti]

I'd rather have qcodes to have pinned dependencies on release, no ? So it behaves the same. Like any other software people use, unless they hack on python then the dev version has no pinned but open intervals (i.e. xxx >= 0.1) .

[alexcjohnson]

I'd rather have qcodes to have pinned dependencies on release, no ?

Curious to hear other folks' thoughts on this, it's certainly more flexible for users (particularly if you're integrating with other packages that have their own requirements) if we do open intervals, and a quick look around at some of the packages I have installed on my own machine shows them generally open. But you're right that for our own purposes pinned is easier.

Perhaps we could start out pinned but plan to open, once we have the test runner set up to check a few different version combinations, like minimum for all packages, latest for all packages, and a couple of combinations in between?

[giulioungaretti]

I think, we need open (x> 1) intervals on a second thought 👿 . And just save the version in the metadata.