211–220 of 222 posts
Have you used nuget for .NET? I have to say I've never once run into any of the problems I encounter sometimes weekly with NPM for Node.
Earlier quoted context omitted.
[0] https://go.dev/blog/appengine-gopath gopath / workspaces original [1] https://go.dev/blog/migrating-to-go-modules current system [2] https://news.ycombinator.com/item?id=34310674 goproxy agressively polling sourcehut It's worth recognizing that go isn't alone in dns-based namespacing : java's maven/gradle use the same strategy: https://repo1.maven.org/maven2/gov/nih/imagej/imagej/1.47/
Fantastic links, thanks! I like the DNS-based way so much I am still trying to tease apart its disadvantages.
Earlier quoted context omitted.
Well, not DAG, because the A is for acyclic, and dependency graphs can definitely contain cycles.
In the case of immutable builds (and hence immutable dependencies), dependency graphs cannot contain cycles. At most they can have the same package occur twice in the graph, but with different dependencies or different build options.
Have you used nuget for .NET? I have to say I've never once run into any of the problems I encounter sometimes weekly with NPM for Node.
Indeed, people act as if package managers were some Turing award level problem because they havent tried ecosystems that at least try to provide good ux like rust or .net
Earlier quoted context omitted.
> It relies on DNS for package identity. The flip side of this is that it never has to worry about naming collisions or namespacing: Your public package name must be a URL you control. Additionally, there is no requirement for a centralized package facility to be run. The Golang project is currently running pkg.go.dev, but that's only been in the last few years; and if they decided to get rid of it, it wouldn't signi…
Java enforces domain name ownership as well; I can’t publish to maven central under io.netty. This removes a whole slew of attack surfaces that JS and Python have, and leverages an existing “prove you are who you say you are” infra
The advantage being, if you later lose access to the DNS domain that you used to publish an artifact to Maven Central, the new owner doesn't automatically get to compromise your artifact for all (new) users.
Earlier quoted context omitted.
Doesn't look like it, see module drama in Go, while Rust is having an npm like ecosystem of tiny crates. Plus none of them handle binary library distribution as some of the packing models that came before them.
Can you give me a one-liner about module drama in Go?
Earlier quoted context omitted.
There's already a module proxy (pkg.go.dev) by default in new versions of Go, for just that purpose. In fact, one could argue that the automatic proxy is "Rube-Goldberg"-like: It works great normally, but if you need, for instance, to pull from a repo you just pushed to, you have to track down the magic rune to type to get `go get -u` to pull directly from your repo, rather than using the cached copy at pkg.go.dev.
> There's already a module proxy (pkg.go.dev) by default in new versions of Go, for just that purpose Is it really a proxy in this sense? I was under the impression that it did not keep cached copies of the code, just some metadata, so that it didn't actually protect about someone removing their repo. Maybe I'm wrong about that though.
My impression, particularly based on the timing, was that the introduction of the proxy was in part directly in response to the "left-pad" fiasco. One thing it will also do is automatically publish your docs, if it can detect an open-source license. That would certainly require keeping a copy around.
Earlier quoted context omitted.
> In reality there's been plenty of research - and for decades - that is not being used. Can you link what you're referring to? Genuine request, I'm curious and keen to learn more.
Perl users have been using CPAN for decades.