Folder naming reasons

[olebedev]

What is the reason to use $GOPATH/_vendor folder instead of $GOPATH/src?

[mattn]

This way force to use of the src directory for the developer.

[olebedev]

Clear.
I think we need to put a variable _vendor to the config by default. And put it to the command line option. This will work with the utility on an advanced level. I am pleased to offer my commit =)

Tell me what you think.

[mattn]

If it espoused, I'm thinking the configurable directory should be for the each-users. So it's not a variable maybe.

[olebedev]

My suggestion is:

And put it to the command line option.

Of course it can't be only variable. It should be reconfigurable. With value by default.

[olebedev]

By the way, I think that the tool should be $GOPATH oriented. Because any project requires isolation at $GOPATH level.
And if the developer does not understand what happens when the tool works, this is not a problem of tool. The Unix philosophy told us "Write programs that do one thing and do it well.".

I would really like to do this is to offer work. Otherwise I'll have to fork and small redisign. @mattn, what you think?

[mattn]

How about environment variable GOM_VENDOR_NAME ?

[olebedev]

Yeah! That's it.

[matthewbelisle-wf]

@mattn and @olebedev

I'd like to make some more changes to how this tool interacts with $GOPATH. It was originally just a _vendor folder like this:

├── Gomfile
└── _vendor
    ├── pkg
    └── src

And then Oleg added the GOM_VENDOR_NAME env variable so that it could be something like this:

├── Gomfile
└── custom_vendor
    ├── pkg
    └── src

But my idea is, what if gom install just installed the packages into $GOPATH itself? That seems like a simpler and cleaner solution because instead of having to do gom run, gom test, gom doc etc, you would just use the standard go run, go test, go doc etc. What do you think about this? If it sounds like a good idea to you, I am excited to make the changes myself and submit a pull request into this repo. I also think this change would attract more users to Gom (like people with Google Appengine projects).

P.S. - Matsumoto さん、素晴らしいパッケージマネージャーを開発してくれて誠にありがとうございます！Godep より使いやすいと思います。

[olebedev]

@matthewbelisle-wf, your idea exactly like mine.
But as I understand it, @mattn wants to keep the backwards compatibility. Therefore it was decided to add a variable GOM_VENDOR_NAME.

Now you can do what you want with: export GOM_VENDOR_NAME=$GOPATH, that mean that the packages will be installed into $GOPATH itself.

[mattn]

How about new flag --install-gopath? For example, gom install install bins into custom_vendor/bin but gom install --install-gopath install bins into $GOPATH/bin. I don't know --install-gopath is good name or not.

Or gom install-path instead?

[olebedev]

Yeah! Good idea.
I think the flag should be -g, --install-gopath. Add another command is not necessary, IMHO.