nfeske
commented
4 years ago I anticipated this question. :-)
You can pin the versions by creating a custom .goarc file anywhere in the path that leads to your project. See goa help config for a description of this mechanism.
Hence, you can create such "lock file" by either copying the current share/goa/goarc file to your custom .goarc file. You can also choose to only pin parts of the versions. You can even have multiple .goarc files for pinning different archive versions at different parts of your directory hierarchy. In this case you can get all versions observed by goa for a given project via the goa archive-versions command, which you can - again - take as input for .goarc files.
So at the moment, versions that my software is compiled with are changed when I update the tool. This is undesirable.
That was actually my intention behind the goa update-goa feature. evil-smile. As a matter of fact, at the current stage of development, I'm developing goa and the archives in tandem. This way, I can introduce new Goa features along with new depot archives with no long-winded explanations needed. Later, I plan to introduce a different goa branch for each Genode release and keep the archive versions fixes for each branch. But that is not now.
At the moment, the versions of components come from
share/goa/goarc. So at the moment, versions that my software is compiled with are changed when I update the tool. This is undesirable.Ideally, Goa would write the current dependencies into a lock file when dependencies have been resolved. This lock file can then be checked into version control.
Good examples of this workflow are the Haskell Stack, or Cargo lock files, npm lock files, etc.