> In contrast, if someone proposes "C++ should have a package manager", exactly _who_ will implement and maintain the canonical repo mirror? This is not independent lines of work that GCC, Clang, Microsoft, and Intel can do on their own. Even if we hypothetically extend the website "isocpp.org" to actually start hosting the canonical C++ repos instead of just blog posts about syntax proposals, _who_ is paying for it? Again, there is no single entity like Joyent/Mozilla/GoogleInc that raises their hand and says, "We'll set it up".
Literally no one is required to do any of that. That is the answer. Plain and simple.
> I think the disagreement is rooted in how we compare ISO C++ committee vs Google Inc. To me, releasing a C++20 language specification* does not say anything about implementing a canonical repo* so that a command line tool magically works the way people expect.
But I'm saying that's not how Go works at all. The dependencies are hosted on GitHub, GitLab, or wherever else.
There is no central package repo. There is no "canonical repo".
Package discovery tools are not very relevant to the discussion. You can have a package manager without having a discovery tool or a central repo. Searching GitHub to find a C++ package, then adding that repo as a dependency of your current project seems like it would be entirely reasonable, if C++ had a standard package manager that worked. Some community members might build a website to help you find popular packages... but that discovery tool doesn't interact directly with the packages at all.
proxy.golang.org is a proxy. No one publishes packages to it, and you don't have to use that proxy. You can use no proxy at all, which was the default once upon a time, or your company can host a proxy, or you can potentially find some random third party proxy online. The proxy isn't where packages are hosted -- it's just a means of accelerating downloads, if GitHub were slow, for example.
C++ code is hosted in a myriad of locations. The Go approach is to specify the GitHub repository that you're depending on, and that repo will be cloned by the package manager in your terminal. The `go.sum` file contains hashsums to verify that the dependency you downloaded is untampered with since the last time you fetched it, and those hashes can also be used by any proxy that happens to be used.
Go's package management system is truly distributed. It isn't centralized at all. Yet it still supports SemVer, downloading the correct, exact version of a dependency, checking the integrity of dependencies, recursively collecting dependencies of your dependencies, etc. All the features you would expect out of a package manager.
Unlike Cargo in Rust, someone can delete one of these repos from GitHub and cause a real mess. `go mod vendor` is an option for anyone who prefers to vendor their dependencies.
Google has certainly provided some nice web tooling around the Go Modules system, but none of it is integral to the type of package manager that I'm proposing would suit the C++ dependency model. Go's package manager is very distinct from what you were discussing with Cargo, NPM, and others. It's much more attuned to the problems that C++ faces, and it walked a similar path to what C++ will inevitably have to do.
Which honestly mostly works well, except when it doesn't. There are at least a few module/version combos where people have shifted a version tag on their repo over time, leading to the (unfortunate) reality that you end up with different modules depending on if you fetch it through a proxy, or directly. Not entirely surprising, this can (and will) cause build failures.
Source: I build lots of Go modules for fun (well, specifically, I have some automation to do it for me) and notice these things, when I get more failures than expected. http://github.com/vatine/gochecker for anyone wanting to play along from home (the 1.16 release report is on hiatus, as there was a LOT of things that didn;t work smoothly this time).
Literally no one is required to do any of that. That is the answer. Plain and simple.
> I think the disagreement is rooted in how we compare ISO C++ committee vs Google Inc. To me, releasing a C++20 language specification* does not say anything about implementing a canonical repo* so that a command line tool magically works the way people expect.
But I'm saying that's not how Go works at all. The dependencies are hosted on GitHub, GitLab, or wherever else.
There is no central package repo. There is no "canonical repo".
Package discovery tools are not very relevant to the discussion. You can have a package manager without having a discovery tool or a central repo. Searching GitHub to find a C++ package, then adding that repo as a dependency of your current project seems like it would be entirely reasonable, if C++ had a standard package manager that worked. Some community members might build a website to help you find popular packages... but that discovery tool doesn't interact directly with the packages at all.
proxy.golang.org is a proxy. No one publishes packages to it, and you don't have to use that proxy. You can use no proxy at all, which was the default once upon a time, or your company can host a proxy, or you can potentially find some random third party proxy online. The proxy isn't where packages are hosted -- it's just a means of accelerating downloads, if GitHub were slow, for example.
C++ code is hosted in a myriad of locations. The Go approach is to specify the GitHub repository that you're depending on, and that repo will be cloned by the package manager in your terminal. The `go.sum` file contains hashsums to verify that the dependency you downloaded is untampered with since the last time you fetched it, and those hashes can also be used by any proxy that happens to be used.
Go's package management system is truly distributed. It isn't centralized at all. Yet it still supports SemVer, downloading the correct, exact version of a dependency, checking the integrity of dependencies, recursively collecting dependencies of your dependencies, etc. All the features you would expect out of a package manager.
Unlike Cargo in Rust, someone can delete one of these repos from GitHub and cause a real mess. `go mod vendor` is an option for anyone who prefers to vendor their dependencies.
Google has certainly provided some nice web tooling around the Go Modules system, but none of it is integral to the type of package manager that I'm proposing would suit the C++ dependency model. Go's package manager is very distinct from what you were discussing with Cargo, NPM, and others. It's much more attuned to the problems that C++ faces, and it walked a similar path to what C++ will inevitably have to do.