-
Notifications
You must be signed in to change notification settings - Fork 1k
dep ensure -add should not depend on Go code #1312
Comments
eek, that's definitely an oversight. it makes sense that the requirements would be different for
while i think i know the general sentiment behind this - the essential model of "keeping things in sync" instead of allowing arbitrary state mutations - if there are any specific things you're chafing against, please do let us know. while we're settled on the base model, we're now increasingly entering a phase of sanding off the particularly onerous edges. |
I'm fairly at peace with |
This is important to me because I want to use |
|
this is usually a bit of a different case, as having build errors in all your dirs usually occurs when you're mid-refactor. the problem with continuing through in that case is that to skip all of those packages with errors would mean skipping all the imports that you probably picked up in previous (it's important to note that it's fairly hard to reach this case, as there must be Go files that fail validation prior to the end of the |
I took a quick look into this. When the error is just handled as non fatal, the user will get the following message when adding a dependency to an empty project:
This is true for all calls, even for additional and Still it feels correct to allow running The log output without having a fatal error is not even confusing:
|
you can pass multiple arguments to
that's the only option. anything else would require hanging on to additional state in a sidecar somewhere, which means more files on disk. if you want to permanently guarantee that something not in your imports is still included, you need a
eh, i could be convinced either way? on the one hand, it is a harmless no-op; on the other, what's the benefit of having it not complain to the user when we know the inputs are nonsensical? that seems like a useful guardrail that could help inform the user as to dep's intended use pattern. |
IMHO the log output from the no-op explains way more than the short error message. Of course, than the fix could be a better error message as well ;) I don't really have a strong opinion on this, but I took this as a chance to get my hands dirty on the code. I made a small PR out of it but can't judge my self if it should go through. |
I'm running into a case where this would be beneficial (to run dep ensure on an empty project). This way, |
@trushton that's a slightly different case, and should be covered by |
An additional data point: the docs contradict what the current functionality is (emphasis mine):
$ dep ensure -add github.com/foo/bar github.com/baz/quux https://github.com/golang/dep/blob/master/docs/new-project.md |
crap. I'd forgotten that we hadn't fixed this yet when i wrote that. thank you for calling attention to it. if you wanted to submit a PR with a parenthetical caveat link to this issue, similar to elsewhere in the docs when there's an outstanding bug... i wouldn't cry about it 🙏🎉 |
If the project won't build, maybe it will build after the dependency is added/sourced? (shrug) lol |
What version of
dep
are you using (dep version
)?What
dep
command did you run?I ran this in an empty project, so I could start my
main.go
file.What did you expect to see?
The usual warning about this dep being ephemeral.
What did you see instead?
dep ensure -add
is already a "stop trying to be smarter than me, I mean what I say" command, it shouldn't complain about an empty project.The text was updated successfully, but these errors were encountered: