While you can, in practice, just create a git repository for each go program and put your dependency tarballs there, it's cumbersome. I think there is a way to make dependency tarballs unnecessary in go-module.eclass without EGO_SUM in ebuild. Raku and janet are fine languages for parsing go.sum. Thus, a helper for go-module.eclass can be written in raku or janet to parse go.sum and automatically generate tarball URIs for SRC_URI. The helper can also be called to extract the tarballs into a temporary vendor directory used by go-module.eclass. It still requires bigger manifests, but does manifest size really matter unless it's too big? How does anyone think of this?
It sounds like you are proposing a replacement for get-ego-vendor and most of the eclass code. I could probably take get-ego-vendor further and have it generate values for SRC_URI directly instead of using EGO_SUM. This would do what you are proposing, but it still doesn't solve the underlying issues. The first issue is the size of the manifest. Manifests can be multi-thousands of lines long in this setup, and that has been sited as a problem by QA. The more concerning issue is the size of SRC_URI. SRC_URI can have thousands of entries, which will cause $A to be too big to be exported to the environment. This will break portage.
Is there a third way?
I don't know of one unfortunately. The only thing I can come up with is if the package manager would allow us to fetch the dependencies during the build as proposed in bug #833567; however, as you can see by reading this bug, this doesn't look like it is going to happen any time soon.
If you come up with a proposal other than this, I would really like to hear it, so feel free to let me know. Thanks, William
