GitLab

In #28325 (moved) we are working on enabling go.mod support for our Go based projects. While that will be an improvement in that we don't need to work around a new default anymore, it does not solve the question how we can easily update all the dependencies of a project and the dependencies of those dependencies. That's the scope for this ticket. Besides #28325 (moved) we should keep in mind that we might want to think about how we want to handle go modules in the future. Right now, we have a project per module in tor-browser-build. Maybe that's not a smart thing with the growing amount of projects we have. Either way, the solution for this ticket will have an impact on that, so we should take the question about how to handle the module-project relationship into account.

For the dependency update path forward we a bunch of possible options, some already mentioned in #28325 (moved) (in no particular order):

1. Use go mod vendor to vendor in the dependencies and then build with -mod=vendor to use the vendor folder with the dependencies.

2. Refine the gomodtorbm script written by dcf/cohosh (see: #28942 (moved) and #33576 (moved))

3. Use go mod download to fetch dependencies into the cache and then point, during the build, with GOPROXY to the cached files (that's feeling similar to what we use for our Gradle dependencies right now).

There might be more than those three.

boklm had a nice idea of restructuring our go projects in a way that we'd only have one go-module project and we could list all needed dependencies directly in the respective project under input_files (see: comment:42:ticket:28942). That might be orthogonal to 1) and 3) but might actually help with 2). not sure.