dep ensure -add should add constraint to Gopkg.toml even if imported already

[FiloSottile]

Edit by @carolynvs: After discussion, we would like to see the following behavior:

1. Import a new project in my code.
2. Run dep ensure. This adds a project entry in Gopkg.lock but not Gopkg.toml.
3. Later realize that I want to have a constraint set in my manifest. Instead of looking in the lock to for the locked project and figuring out what to add to the manifest manually I want to...
4. Run dep ensure -add github.com/pkg/example and dep will infer the appropriate constraint from the existing locked project, and append the constraint to the manifest. If a constraint or required is already in the manifest, an error is still displayed as it does already today.

---

(_assuming you still take UX reports_) (carolyn: We do! ❤️)

Today I merged a PR in a repository I manage with dep. The PR added a dependency but did not vendor it, so I updated dep and ran dep ensure to add it.

In #1313 I learned that I want constraints for my direct dependencies, but just running that command did not add one, so I tried dep ensure -add github.com/godbus/dbus:

Fetching sources...

Failed to add the dependencies:

  ✗ github.com/godbus/dbus is already imported or required, so -add is only valid with a constraint

adding dependencies failed

So instead I had to go into Gopkg.lock, take note of the version, open Gopkg.toml, copy-paste a constraint, lookup what the behavior of version without operator is (since I forgot), and edit the constraint.

It looks to me like there are two natural flows to add a dependency:

1. -add first
   
   
   
   • decide to add a dependency
   
   
   • call dep ensure -add
   
   
   • import and use it
   
   
2. import first
   
   
   
   • add a dependency
   
   
   • call dep ensure to vendor it
   
   

1 results in a constraint, 2 does not. The preferred result between the two, or even what difference it makes, would be completely opaque to me had I not asked on #1313, and getting there via 2 is clunky.

[FiloSottile]

BTW, https://golang.github.io/dep/docs/daily-dep.html is great.

But the idea that import-then-ensure will only be used for "rapid iteration and off-the-cuff experimenting" is unrealistic.

[FiloSottile]

I was going to suggest that at least -add should add the constraint for me, so that we can say "just always run -add, but it looks to me like that's what it's documented to do. (Row 5/6.)

So maybe just turn this into "-add should infer constraint and add to Gopkg.toml even if imported" or (tell me to) open an issue for that.

[carolynvs]

So maybe just turn this into "-add should infer constraint and add to Gopkg.toml even if imported" or (tell me to) open an issue for that.

👍 I agree it's confusing and annoying how dep works today in this case. I'll update the title and OP to make it clear that is what we would like to change the behavior to. If I have summarized incorrectly, let me know! 😀

[sudo-suhas]

Hey @carolynvs, can I work on this? If yes, could you please give me some pointers on how I could get started on the changes required?

[carolynvs]

@sudo-suhas I don't really have pointers, but if you'd like to work on this, no one else is. :-)

[glerchundi]

I written a small application just to check this, which forces our build to fail and therefore, the developer to include them manually. In case it's useful for you as it was for us.

[mvdan]

Dep was officially deprecated earlier this year, and the proposal to archive this repository was accepted. As such, I'm closing outstanding issues before archiving the repository. For any further comments, please use the proposal thread on the Go issue tracker. Thanks!