Versioned Go Commands
research.swtch.com
Versioned Go Commands
1–10 of 16 posts
Re: Versioned Go Commands
#2TOC for all articles in the series: https://research.swtch.com/vgo.
Links to previous discussions about articles in the series:
Part 1: https://news.ycombinator.com/item?id=16421966
Part 3: https://news.ycombinator.com/item?id=16431299
Re: Versioned Go Commands
#3TOC for all articles in the series: https://research.swtch.com/vgo . Links to previous discussions about articles in the series: Part 1: https://news.ycombinator.com/item?id=16421966 Part 3: https://news.ycombinator.com/item?id=16431299 Part 4: https://news.ycombinator.com/item?id=16433425 Part 6: https://news.ycombinator.com/item?id=16441970
Re: Versioned Go Commands
#4I'm really excited about all this! No more GOPATH, no need for vendor directories; I think this is a positive step forward for Go, and package management in general. I'm also interested in seeing if there's any wider adoption of these ideas in the larger package management ecosphere.
One thing I've been mulling is whether this setup makes more sense in compiled languages than it would with dynamic languages. In the latter, your code base is your executable, so there may not be much difference between this and having a traditional vendor directory.
Of course, using semantic import versioning is something that can stand alone.
Re: Versioned Go Commands
#5I have been out of the go space for a while, and recently took up a small project that uses it.
I was glad to see that 3rd party tooling (VSCode extension for example) had improved a lot. And after the initial hump, using the dep[0] tool was a breath of fresh air compared to the cludgy alternatives back in 1.4/1.5.
As of a month or two ago dep was slated to become the "go dep ..." command. I'm really curious (and not in a demanding way.. but legitimately curious) why:
1) it's taken them this long to stabilize dependency management, in what seems like an otherwise polished, well supported ecosystem?
2) they could abandon a well thought out, reliable community supported tool that was endorsed by golang itself?
After a lot of trying I'm finally warming to the language but the community and ecosystem still leave a lot to be desired. I'll be interested to see how vgo plays out. Third time lucky I guess (get, dep, vgo)?
Re: Versioned Go Commands
#6I'm really excited about all this! No more GOPATH, no need for vendor directories; I think this is a positive step forward for Go, and package management in general. I'm also interested in seeing if there's any wider adoption of these ideas in the larger package management ecosphere. One thing I've been mulling is whether this setup makes more sense in compiled languages than it would with dynamic languages. In the l…
Vendor directories are the simplest way to include the deps with your project. Removing that ability would complicate many existing projects. Now instead of git, we will need an additional tool to properly vendor our deps .
Re: Versioned Go Commands
#7I have been out of the go space for a while, and recently took up a small project that uses it. I was glad to see that 3rd party tooling (VSCode extension for example) had improved a lot. And after the initial hump, using the dep[0] tool was a breath of fresh air compared to the cludgy alternatives back in 1.4/1.5. As of a month or two ago dep was slated to become the "go dep ..." command. I'm really curious (and not…
The dependency management story is awful because Go is developed for Google’s purposes, and Google builds from a monorepo.
Re: Versioned Go Commands
#8I'm really excited about all this! No more GOPATH, no need for vendor directories; I think this is a positive step forward for Go, and package management in general. I'm also interested in seeing if there's any wider adoption of these ideas in the larger package management ecosphere. One thing I've been mulling is whether this setup makes more sense in compiled languages than it would with dynamic languages. In the l…
Vendor directories are the simplest way to include the deps with your project. Removing that ability would complicate many existing projects. Now instead of git, we will need an additional tool to properly vendor our deps .
I am afraid I don't exactly agree. If you are publishing a library, for one, it's best not to include any vendored dependencies to begin with. But, ideally, no one should include vendored dependencies, whether a library or executable; those are things that can be fetched at build time. ("But, what if the dependencies disappear?" you may ask—this would be handled through the caching proxy in Russ' proposal.)
The additional tool you would need to build your software would be vgo.
Re: Versioned Go Commands
#9Earlier quoted context omitted.
Vendor directories are the simplest way to include the deps with your project. Removing that ability would complicate many existing projects. Now instead of git, we will need an additional tool to properly vendor our deps .
I am afraid I don't exactly agree. If you are publishing a library, for one, it's best not to include any vendored dependencies to begin with. But, ideally, no one should include vendored dependencies, whether a library or executable; those are things that can be fetched at build time. ("But, what if the dependencies disappear?" you may ask—this would be handled through the caching proxy in Russ' proposal.) The addit…
For smaller teams/apps, it's super-handy to be able to just include dependencies in the repo. I'm guess this is one of the capabilities vgo will gain in response to community feedback.
(The Go folks have a bit of a blind spot for environments that don't have heavy duty infra. Recall how their initial solution to a montonic clock was "just arrange for your ntp server to not do that...")
Re: Versioned Go Commands
#10I have been out of the go space for a while, and recently took up a small project that uses it. I was glad to see that 3rd party tooling (VSCode extension for example) had improved a lot. And after the initial hump, using the dep[0] tool was a breath of fresh air compared to the cludgy alternatives back in 1.4/1.5. As of a month or two ago dep was slated to become the "go dep ..." command. I'm really curious (and not…
The dependency management story is awful because Go is developed for Google’s purposes, and Google builds from a monorepo.
The monorepo seems like a bit of a red herring. A fork maintained in a separate repository (like pressing the fork button GitHub) would achieve the same. In fact, the type aliasing feature was added because Google (and others) struggled to make modifications in single commit, so the atomicity the monorepo could theoretically provide has already proven to not be there in practice.
The main difference is that Google is comfortable with having a fork that they can update from the mainline branch when needed/desired, but will otherwise stay stable for their software. Others, who are familiar with more traditional package tools, are not. And perhaps their concern is justified, but interestingly I've never seen a Go experience report reporting why that approach failed them.