Enforce mkDGitRevision usage outside of libraries
Clarification and motivation
Currently we use mkDGitRevision
inside library code, directly in a contract. It is TH thing that uses IO
internally (runs git
or checks an environmental variable). As far as I know, it is considered bad practice and there is a recommendation to do it in executables. One reason for that coming to my mind is that if we modify only an executable and commit a new version, we want mkDGitRevision
to return newer revision, but the library will likely not be recompiled. Also we don't want anyone who depends on a library to run mkDGitRevision
for the library, it just doesn't make much sense.
Also I want to point out that each our contract has doc $ $mkDGitRevision morleyRepoSettings
and I think we really want each contract to have it. So I propose to enforce using mkDGitRevision
in executables and passing its result to some function that produces documentation (probably buildInstrDoc
or buildLorentzDoc
). It can insert doc $ $mkDGitRevision morleyRepoSettings
thing automatically (it can be made optional).
Acceptance criteria
-
buildInstrDoc
orbuildLorentzDoc
should takeDGitRevision
(or something similar) as an argument and insert it into the contract. We should write that people should use it in executables. - Our contracts updated accordingly.
- Our projects that use
morley
are updated as well.