Hacker News Reader

Comment by CSDude | Hacker News Reader

I hate go packaging. I want to fork a package for my private purposes, maintain it in my hosted repo or somewhere private, but no, I have to change all the required import paths to my repo path. Or I have to provide it in vendor folder, or have custom gopath folders, but then go get does not work, I have to git clone and put it in some weird old repo's path. You could use relative paths, or package names but no, you had to use site urls so you could make it harder for anyone that does not work open source or private. I have not found a better solution for forking a repo and working it on my own besides vendor folder solution.

View on HN

> I have to change all the required import paths to my repo path

GO15VENDOREXPERIMENT=1 will be default behaviour in Go 1.6. So you don't have to rewrite the import paths anymore.

> Or I have to provide it in vendor folder

What's wrong with that?

> What's wrong with that?

Vendoring external dependencies adds a lot of noise to your git history. Especially with github's UI it's easy to miss an important change because of skipping trough the vendor changes or getting the "too many changes to display" message.

> Vendoring external dependencies adds a lot of noise to your git history.

This is my concern as well. Is it possible to use git submodules in vendor directory? Looks like it is possible [1].

[1]: https://github.com/golang/go/issues/12573

will go get download to the vendor folder first?

Honest question: Isn't this approach one of the selling points of Go? The designers of the language decide what is the right way to do things, and then that's how it's done, leading to simplicity? It's not for me, but these restrictions are often pushed as a feature (others here have explained the reasoning in this particular case).

An advantage of using C is its longevity. Go was designed to be a possible replacement/redesign of C (with Ken Thompson as an initial author). So this design decision doesn't make any sense, since URLs are some of the most volatile things in the programming world.

I'm right now TAing a course which uses Go. Tons of people are having trouble with this, and the interaction with $GOPATH.

This course has fourth year undergrads and masters' students. Most are familiar with some languages but aren't too used to production code practices (basically, one of the target audiences for Go -- be simple so that everyone can ramp up). Some have said that they preferred submodule deps or pythonesque easy-to-copy and easy-to-play-with import statements (and pip install) over this.

There is the valid argument to be made that any model for publishing your package is going to be tougher than a simple github URL, but it doesn't have to be much worse. With Rust, for example, you need to run `cargo login` once (which will direct you to a page where you can make an account if you need to) to set up, and then `cargo publish`. Pretty easy to learn.

I like a lot of things about Go, including it's simplicity. I wish I had more time to write Go, because it's a fun language to work with. But $GOPATH and URL-packaging are not amongst the Go features which I like.

https://github.com/tools/godep should solve all these issues. Yes, it vendors packages. But it happens completely automatically and you can switch to your own forks at will.

Reply on news.ycombinator.com