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 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.