[feature request]: add concept of a devDependency

[agnivade]

$dep version
dep:
 version     : v0.4.1
 build date  : 2018-01-24
 git hash    : 37d9ea0a
 go version  : go1.9.1
 go compiler : gc
 platform    : linux/amd64

Currently, I have the linter flow in my pipeline. Therefore, I need to install github.com/golang/lint/golint separately because the code does not depend on it, but still it is needed as a dev dependency.

It would be great if it could be managed by dep so that I don't have to use a separate go get command to do extra stuff.

P.S. - Apologies if this is already being worked on. I searched the issue but could not find anything like this. I think this is a common enough use case, so I am wondering how is this tackled by others ?

[mvdan]

Something that I (and perhaps others) have done in the past is to import the package in a silly way, to make dependency management tools pull it. For example, import all the linters (even if they are main packages) in a Go file that will never be built, e.g. behind an "ignore" build tag.

[agnivade]

Interesting. A bit hackish, but certainly a solution. It would be great though if dep had proper support for it.

[sdboyer]

Very early designs separated out the idea of a "dev dependency" explicitly, but it made less sense as time went on: required, with perhaps a little help from virtualgo, can probably get you what you want.

[agnivade]

Hmm .. definitely better than the build tag hack. But the fact that there is no proper way to install and run the binary is bit of a bother. Installing virtualgo is an overkill. Not sure why "it made less sense as time went on".

I think dep should atleast expose a way to build binaries from packages installed through required and put then inside something like vendor/bin. Or maybe it can do it automatically in the dep ensure stage if required can contain flags to install the binaries or not.

And lastly, a way to run those binaries. Something like dep run; similar to the approach npm takes where commands specified inside package.json are automatically looked inside node_modules folder.

Until then, doing a simple go get -u github.com/golang/lint/golint is good enough for me.

[sdboyer]

Not sure why "it made less sense as time went on".

This is filler for "it's a long story, and i don't have time to write it out right now."

I think dep should atleast expose a way to build binaries from packages installed through required and put then inside something like vendor/bin. Or maybe it can do it automatically in the dep ensure stage if required can contain flags to install the binaries or not.

And lastly, a way to run those binaries. Something like dep run; similar to the approach npm takes where commands specified inside package.json are automatically looked inside node_modules folder.

It's out of scope for dep to directly perform compilation. Not because i don't think the use cases are important, but because it steps too much into territory of things the go toolchain already does. Adding support for it, while certainly convenient, makes the already-very-difficult task of navigating the transition into the toolchain more difficult.

[agnivade]

Understood.

dep need not perform the compilation. IIUC once its integrated as part of the toolchain, this would be simpler to tackle ? As long as the toolchain as a whole is able to do this some day, I am good.

Thanks for all your work !

[sdboyer]

Yes, very much simpler to tackle sane workflows around this once it's clear what exactly the new toolchain will look like.

thanks for understanding!