Comment by imsofuture | Hacker News Reader

Comment by imsofuture | Hacker News Reader

Parent Full thread

Go vendoring gets such a bad rap undeservedly. In practice it's the simplest and most straightforward dependency system (since 1.4/5 added vendoring) I've used.

Step 1: Check out code that you want to use. That's actually the only step and you can do it by hand, or with one of a multitude of tools. All the tools differ slightly, and any metadata or manifests or things like that they do aren't compatible, but the code they put in your repository is, enabling anyone to clone a repository, and instantly build the exact version of all your dependencies.

Imports also aren't full git URLs, they can be as a convenience that tells you where to get a package. You can't `go get` a specific tag, but that's fine, because `go get` isn't a package or dependency manager, it's just a convenience to grab code to your system, not to freeze a version as a dependency into your project.

Frankly, the amount of people that put their nose in the air at go is just fine with me, just makes it more of a 'secret productivity tool' I guess.

Edit: not to say it wouldn't have been nice if `dep` had been the one blessed path at version 1. Still, I have extremely little to complain about with the language and tooling since 1.4/1.5.

The fact that the full url is used to import packages make it impossible to fork a repository.

Once you forked it, you have to change all the imports across the repo, and then it's kinda either very hard to make Pull Requests, or pull the new commits from the original repo.

This is one thing I really dislike about go dependencies.

If you have a solution for this, let me know, I would be very interested to know more about it.

But overall, I love go. I use it all the time anyway.

You don't have to change the package name just because it's forked.

I threw together an example of doing this with `dep`. I forked Fatih's color package, and am using it as `github.com/fatih/color` no problem: https://github.com/sofuture/colortest (forked dep here: https://github.com/sofuture/color)

As I said in my other comment (https://news.ycombinator.com/item?id=15632049)

It works for you because it's a small project and you are not actually importing other of your own packages inside it.

But if you look at "echo", it import some other "echo" packages inside of it.

That doesn't matter is what I'm saying :) The package name of my fork isn't changed, and doesn't need to be, regardless of what else uses it. The only thing I had to do was specify 'use my fork's repo' in the Gopkg.toml file.

Edit: I'll fork echo in my example and show you.

Okay, updated my example with `echo`. Check it out:

Using the original package name: https://github.com/sofuture/colortest/blob/master/main.go#L7

I can refer to my fork: https://github.com/sofuture/colortest/blob/master/Gopkg.toml...

Oh I see.

Thank you for the example :)

You don't have to use the full url to import a package. The name of a git repository doesn't have to match the remote name though, so I don't see why it would be a problem to fork a repository.

Let say I would like to fork "echo".

Echo is using some imports to their own packages inside the project.

IE: https://github.com/labstack/echo/blob/a098bcd3b0c445dde3d380...

So if I fork "echo", I have to replace the urls in their imports so it imports my fork packages.

I agree venturing is actually good with just a simple folder, though IMO (with the benefit of hindsight), gopath was a mistake, and a per project vendor folder for dependencies would make much more sense for collaborative projects outside large companies.

Go get does have support for tags, but it was intended for they have code in go get to find tags like go1 and go2 which are as yet unused (I wish they'd used it for dependency version tags like v5.2 etc instead, it may never be used):

https://golang.org/src/cmd/go/internal/get/get.go#L524

Really some simple additions to go get would have gone a long way - recognise semantic version tags like v1.2 on go get and put them in vendor with some command like 'go vendor my/dep -v 1.2'.

Not really sure they need diamond dependencies, updating them automatically up to version x, manifest+lock files and all the other intricacies which in theory a package manager should solve - humans can resolve them as they come up and in real life use they're not a huge deal (as the incredibly simple go get we currently have shows).

Reply on news.ycombinator.com