Bonjour,
It turns out adding go-fed as a dependency to Gitea adds 22MB to the repository and over 700 files, because most of them are generated.
go get github.com/go-fed/activity/streams@master
go mod vendor
Since Gitea is trying to keep its footprint to the minimal, I’d like to know if this is acceptable.
What do you think?
This definitely raises a larger discussion if we even want to continue vendoring our dependencies. We’ve removed generated files for CSS/JS, and we of course don’t vendor our node.js deps, so perhaps it is time to revisit vendoring our go modules. I know some downstream packagers of Gitea may need to be notified as they build Gitea in a CI without access to network, so we could probably distributed the vendor dir similarily how we do with other generated files (upload them via zip to dl.gitea.io in the appropriate directories).
That sounds like a sensible path forward. Is there a way to reach out to people/organizations who depend on vendoring? They may be willing to participate/contribute to the effort in order to be able to upgrade in a backward compatible way even if the vendor dir is external.
In your opinion can the go-fed dependency be added (22MB) before revisiting how the vendor dir is distributed? Or is it a blocker?
Someone from such a downstream packager here 
(not the Gitea package maintainer though)
At least in the case of Nix/NixOS it would suffice if there is an extensive list of dependency packages and their versions, then we can just package these as well and supply them as build inputs.
It’s just important that no network access is necessary during build and that dependencies can be specified unambiguously.
I’m agree with @techknowlogick about some downstream packagers of Gitea may need to be notified as they build Gitea.
I assume this is the Nix/NixOS package for Gitea:
I’m curious to know if there is a simple way to verify it works as expected, some kind of integration test that would use this specification to deploy Gitea and then launch a browser to verify it renders as expected, make a few API calls, that kind of end-to-end / integration testing. It’s a little bit out of topic here though… sorry about that.
Do you have a specific one in mind? I know of Gitea - Cloudron Docs and a few others. Somehow I did not think of them as “downstream packagers” although they are, just like Nix/NixOS.
Yes, such an automated test already exists for gitea in NixOS, and is run automatically by the CI: nixpkgs/gitea.nix at master · NixOS/nixpkgs · GitHub
That feature of no network acess is required during build is reliable.
PS. Regarding binary size of go-fed activity library, I’d like to refer to this feature request: