lock build/test-time dependencies

[fenollp]

Locking deps that are needed only at build or test time would

1. make fetching them easier: dep ensure
2. allow for more reproducible builds

Example of such dependencies:

1. go tools required by go:generate: schematyper, jsonenums, ...
2. others: golint, gox, go-fuzz-build, ...

If I missed a way to do this with current dep please redirect me :)

[fenollp]

Note: I can't just -add a build or test -time dependency, as dep detects this as an unused package and will try to remove it by itself.

"github.com/wadey/gocovmerge" is not imported by your project, and has been temporarily added to Gopkg.lock and vendor/.
If you run "dep ensure" again before actually importing it, it will disappear from Gopkg.lock and vendor/.

[sdboyer]

you're lookin for required 😄

[fenollp]

Ah I did not find that thanks! I am now using this but I have 2 notes:

1. why have required & ignore lists when these are just mutually exclusive boolean attributes of pkg constraints? In general, why is it that -add does not have a -required flag (as well as -version, -tag or -branch for that matter). Note that having a package listed in required but not as a constraint yet makes dep behave strangely... maybe this behavior is a bug and note that the attribute thingy I'm describing would nullify these kinds of bugs.
2. required does not even fully cover my feature request: some cd vendor/pkg/to/install && go install . && export PATH="$PWD/bin:$PATH" meddling is still required, otherwise locking most dev dependencies is broken. I don't know if binaries can be vendored in Golang nor what it fully implies, but exporting a modified PATH when dep ensure is run does not seem too bad, thus acting like a golangenv. Though it would be way better that vendored source packages have vendored bins.

IMO this is proof that the current state of development-time dependencies is more than lacking: the workaround is unsound and can lead to very surprising bugs to most.
Unless there is a way to have vendored bins (binaries from vendored packages that are only usable from the pkg which runs dep ensure / vendors them), I ask that you reopen this issue. :)

[sdboyer]

why have required & ignore lists when these are just mutually exclusive boolean attributes of pkg constraints?

That's not what they are. They're dual to each other ,
and required is almost exactly equivalent to an import statement (for now). But those things are orthogonal to constraint rules.

The models and mechanisms docs may be helpful.

In general, why is it that -add does not have a -required flag

Because the action of adding a dependency is usually not the same as saying "i want this package to be present in my build forevermore".

i could imagine adding a -require flag that is top-level similar to -add, except that it does inject into the required array. However, because we're currently not able to rewrite the Gopkg.toml in a way that preserves comments, which means that we can't directly write to the required property. So, until that technical hurdle is cleared, it's a non-starter.

(as well as -version, -tag or -branch for that matter).

Constraints are encoded as part of the argument spec. See dep ensure -examples.

Note that having a package listed in required but not as a constraint yet makes dep behave strangely... maybe this behavior is a bug and note that the attribute thingy I'm describing would nullify these kinds of bugs.

No bugs there - it just means you haven't set any rules, so dep will grab the latest version that's out there. Same as if you import something without having a constraint rule. Depending on what versions the dependency in question has available, the behavior can be surprising, but it is, at least, consistent.

required does not even fully cover my feature request: some cd vendor/pkg/to/install && go install . && export PATH="$PWD/bin:$PATH" meddling is still required, otherwise locking most dev dependencies is broken. I don't know if binaries can be vendored in Golang nor what it fully implies, but exporting a modified PATH when dep ensure is run does not seem too bad, thus acting like a golangenv. Though it would be way better that vendored source packages have vendored bins.

IMO this is proof that the current state of development-time dependencies is more than lacking: the workaround is unsound and can lead to very surprising bugs to most.
Unless there is a way to have vendored bins (binaries from vendored packages that are only usable from the pkg which runs dep ensure / vendors them), I ask that you reopen this issue. :)

See virtualgo, and most recently, #1572