<div dir="ltr">For some dependency management systems, trust is implied and not verified. The MacPorts approach can definitely provide benefits here: a dependency is declared with checksums, and it is compared against the downloaded version. This can happen with Ruby gems, Cargo crates, Python packages, NPM, etc. Where there is a single distribution arm (even if mirrored like MacPorts itself), and presumably for some "distributed" distribution systems (Maven? I don't do Java), then MacPorts provides benefits. In most cases, these dependencies are <b>packages</b>, which means that they are fancy tarballs of a subset of the whole development tree.<div><br></div><div>This is not the case for Go, where `go.sum` stores the digest of the dependencies and the "distribution" system is git. Like the Node community, there is a common pattern (especially with large API providers like AWS and Google) of using monorepos. There are ways to use git to only clone specific subfolders (git clone --filter and git sparse-checkout) at tags, and while I cannot guarantee that this is what Go uses, it certainly does not do what the Golang portgroup is doing when you use go.vendors.</div><div><br></div><div>A new release of the whole AWS SDK v2 for Go was cut yesterday, but that's not how the go dependencies are computed. If I just need S3 and ACM, I would use `import "<a href="http://github.com/aws/aws-sdk-go-v2/service/s3">github.com/aws/aws-sdk-go-v2/service/s3</a>"` and `import "<a href="http://github.com/aws/aws-sdk-go-v2/service/acm">github.com/aws/aws-sdk-go-v2/service/acm</a>"`. I might do `go get <a href="http://github.com/aws/aws-sdk-go-v2/service/s3@v1.49.0`">github.com/aws/aws-sdk-go-v2/service/s3@v1.49.0`</a> and `go get <a href="http://github.com/aws/aws-sdk-go-v2/acm@v1.23.1`">github.com/aws/aws-sdk-go-v2/acm@v1.23.1`</a> (those are both the latest versions of the individual service SDKs).</div><div><br></div><div>For go.vendors to work, I have to download the WHOLE repository at `service/s3/v1.49.0` and `service/acm/v1.23.1` tags, which is dozens of times larger than what `go get` pulls down (almost 70Mb each). `go get` on ACM downloads about 7MB of code and dependencies.  If I use ten different AWS dependencies, each MacPorts build machine (and the developer trying to update `go.vendors`) has to download nearly 700Mb of dependencies instead of 50–100Mb (go get will not download dependencies already in its cache) for those ten dependencies.</div><div><br></div><div>This is why I focused exclusively on the Golang portgroup. I don't think that the MacPorts model is fundamentally broken. I appreciate it. But I think that go.vendors is the worst approach for Go, and I think that it makes things actively worse from a port and dependency management perspective because it adds little over Go's existing online mechanisms. If Go mirrors could be treated as targets for `GOPROXY`, then I think we would see substantial benefit. There's a bootstrapping question on this, for how a dependency would make it onto the mirrors in the first place, but I’m raising this to try to get possible ideas for the solution.</div><div><br></div><div>-a</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 16, 2024 at 9:58 AM Kirill A. Korinsky <<a href="mailto:kirill@korins.ky">kirill@korins.ky</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Fri, 16 Feb 2024 10:24:59 +0100,<br>
Nils Breunese wrote:<br>
> <br>
> Allowing ports to download dependencies at build time carries the risk of<br>
> those dependencies not being available at build time, which I guess is why<br>
> MacPorts is not a fan of this method. In a corporate setting this is typically<br>
> mitigated by using an in-house repository manager (e.g. Artifactory or Nexus),<br>
> which caches these dependency artifacts. This is kind of similar to MacPorts<br>
> servers storing files, but a repository manager provides interfaces that can<br>
> be directly used by build tools to fetch dependencies, so if we’d have a<br>
> MacPorts repository manager a port developer (or even better: port group)<br>
> could configure a Maven/Gradle/NPM/Yarn/whatever port to use the MacPorts<br>
> repository manager, and then port build should no longer depend on publicly<br>
> available dependencies after the initial build.<br>
> <br>
<br>
Let switch to another and usually missed aspect of automatic downloading<br>
dependency from interten to build a software: security.<br>
<br>
For example Maven as the most popular Java build system doesn't care about<br>
checksums for dependency.<br>
<br>
It ultimatley trust used repository and when it builds software it can inject<br>
any unexpected code.<br>
<br>
>From another side, MacPorts enforces checksuming of dependency that garantue<br>
that it is the same artifact that was used before.<br>
<br>
-- <br>
wbr, Kirill<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Austin Ziegler • <a href="mailto:halostatue@gmail.com" target="_blank">halostatue@gmail.com</a> • <a href="mailto:austin@halostatue.ca" target="_blank">austin@halostatue.ca</a><br><a href="http://www.halostatue.ca/" target="_blank">http://www.halostatue.ca/</a> • <a href="http://twitter.com/halostatue" target="_blank">http://twitter.com/halostatue</a></div>