I have recently become interested in DrWatson. One of the most important features seems to be “tagsave” which allows me to easily associate data with the julia/drwatson project where it was created, including the git version and file.
Now let’s assume that i have code spread among more than one project (+git archives). One might be a package A still under heavy development. The other one is a drwatson project B with scripts that run numerical experiments using A to produce some insights and numbers. To track how i generated results of B, i need to include the git hash of A into the tagsave output too.
I have not found any hint as to how i can easily do this.
Are there any suggestions or existing workflows regarding this?
Or does the tagsave-info somehow include the complete information about both git hashes in a non-straighforward way that i am overlooking?
Let me tell you how I tackle this, because at the moment I am in the exact same situation. I am developing two packages inside the src folder of my project.
At the moment the packages have the formal Julia Pkg structure. BUT, they do not have a .git folder yet. So in my src I have something like src/PkgA/src/PkgA.jl. Until I am ready to put these packages on GitHub, I commit all of their code in my “main” git history. Hence, in the eyes of git, the two packages and my normal scientific source are the same source code. Once I am ready to put these packages on GitHub I just track their main branch, so my Manifest.toml by itself tracks their commit and hence I don’t need to have them locally in my src file.
If you do not like this approach, there is a simple alternative. First, put the packages in your gitignore. Then, instead of using tagsave use the tag! function first, which will tag the data dictionary with current git status. Then, manually add two more fields to the data dictionary using the gitdescribe function by explicitly giving this function the path to each of the packages.
At the moment there is no automated way to include several “sub source directories” to tagsave.
Hm, maybe I should write something about this in the docs!
1 Like
Thanks for the detailed answer and the nice package. So in summary there are basically two situations, either the package A is a registered package and so A’s version in project B’s manifest will be part of B’s git commit, or gitdescribe can be used to track it explicitly by hand.
Not exactly. It does not have to be registered. As long as it is on GitHub and a normal package structure so that it can be tracked with add, that’s fine.