Add github commit hash to replica log

[scarlehoff]

I think it might make sense to add to the beginning to the chi2 log of the replica, some information about the "version" of the repository that the code is running.

Possible use-case, I have 100 replicas running in the background in the cluster. I do a conda update somewhere in the middle of them running, now I have say 50 that have run with a different version of the repository, potentially changing results. This would allow me to know if that was indeed the case.

Or there is some fit in the server that we cannot reproduce, this would allow us to know exactly with what commit it was done.

What do people think?

[scarrazza]

I buy it.

[Zaharid]

We have #275 discussing that.

This really should be in vp at some form get written down in every vp invocation and be available for other things to use. The use case for having it in each replica foldert is convincing (although updating the code in the middle of the fit is "chaotic evil").

As #275 discusses, some problems include that this has to work both in development mode (possibly by invoking the git binary) and in release mode (possibly by writing the info somewhere). When i tried looking at what verioneer did I got a big headache and was discouraged from including that in the code. So I think we should have some proper custom make based logic to write the version at install time (unless the setuptools_scm thing which I haven't looked at is an improvement).

[scarlehoff]

This really should be in vp at some form [...] and be available for other things to use.

Agreed.

updating the code in the middle of the fit is "chaotic evil"

😈

I guess a good roadmap for this can be:

1. function that allows any runcard/function to retrieve the git hash (with some information about whether it is the vanilla repository)
2. in the case of n3fit in particular, use said function to write it down

[Zaharid]

On Mon, 27 Apr 2020, 14:07 Juacrumar, ***@***.***> wrote: This really should be in vp at some form [...] and be available for other things to use. Agreed. updating the code in the middle of the fit is "chaotic evil" 😈 I guess a good roadmap for this can be: 1. function that allows any runcard/function to retrieve the git hash (with some information about whether it is the vanilla repository

Yes, but just to stress that we need some sort of buid step that burns the information in the package. I'd probably write a version.py file that computes the __version__ by calling git as a subprocess and a build step that replaces that file with one containing __version__ as a a static string.

…

1. in the case of n3fit in particular, use said function to write it down — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#744 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLJWUWQAS6J22IXDDCF7BDROVYPPANCNFSM4MRWA2YA> .

[scarlehoff]

Actually, rather than a static string I'd have a function like:

def development_version():
    hash = git rev-parse HEAD
    has_been_modified = git diff-index --quiet HEAD --
    return combine_both( )
__version__ = development_version()

which for the conda package could change to
__version__ = 3.43 (git-hash)

[Zaharid]

Isn't that what I said? Also note that parsing git describe --tags --dirty should give the information we want (more or less, including "has_been_modified").

[scarlehoff]

Oh, I understood you wanted to always have a static thing burned down.

[scarlehoff]

Could you check the error? You should only get unknown if git fails to find a repo but if you did dev in theory __file__ should send you to a place under git.

(note that the file replacement only happens for deploy mode)

[Zaharid]

Sorry, commented in the right place now. #748 (comment)

[Zaharid]

@scarlehoff Can we close this?

[scarlehoff]

Yes. I'm guess we forgot about the isuse.
Let me add that at the time of closing the commit information is stored in the <fitname>.json created with each n3fit fit.