On Friday, January 6, 2017 at 3:04:05 PM UTC-5, Jacek Furmankiewicz wrote: > > Hi Daniel. > > I participated in the great Go survey on dependency management a while > back and raised these concerns there. > I read the summary of that once it was completed and was kinda > disappointed to see that none of this points seem to be getting addressed > or even acknowledged as a problem. > > > https://blog.gopheracademy.com/advent-2016/saga-go-dependency-management/?utm_source=golangweekly&utm_medium=email >
When writing that piece, I sought to strike a balance between providing a high-level summary that would be approachable for people who've not been closely following this topic, and providing the sort of detail that those who HAVE been following it want. Unfortunately, that means that some cases, like this one, didn't get mentioned, and don't appear in the docs released by the committee so far. But this issue has been raised in the past, and it is on our radar. In a glide context (and, sorry, I've not responded to that issue you've opened yet), both of these issues touch on some parts of it: https://github.com/Masterminds/glide/issues/372 https://github.com/Masterminds/glide/issues/594 > > Sure, govendor can force using a private repo for a library. Not it does > not force it for all its dependencies, so you're back to the same clunky > management of every single library with a custom path/repo for every single > one of them. > Right, this is one of the key problems. There's another glide issue where someone raised this point, but I can't seem to lay hands on it right now. The crucial feature here is not individual overrides, but a more general ruleset. The challenges that continue to bounce around in my mind all have to do with having clear portability guarantees. > > The core issue is Go's insistence on using the VCS path of a library as > its import path, unlike any other language out there. > There is no way to create a central repo with all packages and point to > it. Even Rust got this right on day one, with crates.io. > The core issue is really about deciding what names - that is, import paths - mean to the dep mgmt tooling. I don't want to try to crack open the whole problem on this thread here, as it touches too many different problems for productive drive-by discussion. But to my mind, when we tackle this problem (and it is part of the plan), solutions for a bunch of things will fall out pretty directly therefrom: 1. Transparent mirroring/proxying of interactions with sources 2. Package/version whitelists and/or blacklists (something you mentioned earlier) 3. Simultaneous development on multiple local projects that import each other 4. A central package registry, should we decide that's a good idea 5. If #4, then certainly, the ability to run your own package registry So, while this isn't our immediate priority, it's certainly not forgotten, either. > > I understand this was one of the opinionated decisions the Go creators > made in the early days, > but the end result is that we simply cannot even touch Go as a potential > language. > > I don't think this is a side effect they envisioned when they made this > decision. :-( > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
