Dep: Only allow literal version strings as CLI constraints

[sdboyer]

In the requested "air your grievances" discussion on reddit, concerns about how adding new dependences works were raised. i didn't understand them initially, but it finally clicked. This:

$ dep ensure -add github.com/foo/[email protected]

gets treated with an implicit caret, which means that the system ends up selecting the latest version in the 1.x.x range, rather than the literal that the user just put in. the use of implicit carets is controversial enough in Gopkg.toml - #929 - but doing this is just silly. much of the reason why we do implicit carets in Gopkg.toml is because we need them to endure well over time, in multiple scenarios. but CLI instructions are ephemeral. there's just no reason to do it.

really, we/i just didn't account for this in the new command spec. as a result, the arg parsing logic stayed the same from back in the old model, where we were expecting all the manifest manipulation to be done automatically by the tool. in that context, we had to support the full range of options for constraints that might be declared.

the simple-ish thing to do here would be to just stop using semver.NewConstraintIC() when doing the arg parsing. but i think we can go a step further.

it makes very little sense to declare constraint ranges from the CLI. only -add accepts them (and if -update eventually does, it'll only be single versions). but i don't really see a compelling use case for ranges from the CLI. the only case would be if someone's trying to essentially script the creation of a particular Gopkg.toml. but...well, details, but it seems likely that any case where someone wants to do that can be just as easily accomplished by appending the literal TOML string directly.

so, i propose that we cinch down the parsing of dep ensure -add constraint arguments on the CLI to _only_ allow literal version string matches - no implicit carets, no ranges of any kind, and extra operators, implicit or otherwise.

now, when a semver version is passed, we still want to ultimately _record_ the caret in Gopkg.toml. but we make that change only after the solve works, so that we've got the desired version in Gopkg.lock.

[astromechza]

Can I pick this up? (@carolynvs, @sdboyer). Would like to contribute in some way :)

[carolynvs]

@AstromechZA It's all yours! ✨

[sdboyer]

@AstromechZA that's great! please please, let us know what we can do to guide you 😄

[astromechza]

Sorry for the delay :) I've done an initial code survey and have a plan. Just finding some time to sit down and do it.

[sdboyer]

no problem! asking questions here is cool, as is the gophers slack #vendor channel, if you prefer 😄

[astromechza]

Releasing this one - I don't have the time right now. Someone else can take a crack at it.

[sdboyer]

bumping this up to a good-first-pr, especially with @AstromechZA's initial pass at an implementation to work from.

[jr7square]

@sdboyer Can I pick this one up? Really eager to contribute!

[sdboyer]

@jr7square music to my ears! please, have at it 😀 please don't hesitate to ping a maintainer for guidance.

[jr7square]

@sdboyer Sorry for the slow progress, but I promise I'm still working on this issue!

[caynan]

Hi folks, it's been a while that we don't have any progress on this issue...
Do we still want to change the code to behave as @sdboyer proposed?
If so, can I try tackling this problem?

[sdboyer]

we DEFINITELY want this, yes!

let's say this - @caynan, you're welcome to claim it now, and if there's no PR up within a week (WIP is totally 💯💯 fine!), then anyone else should consider it unclaimed.

[caynan]

Cool! I start now :)

[theckman]

@caynan I ended up tacking a swing at this issue, only because I didn't see a WIP PR from you. If there's one I missed please let me know.

[caynan]

No worries, thanks for letting me know... I liked your solution more, I was changing things on a deeper level, but I might have ended up too deep in the habit hole 😄

[theckman]

@sdboyer Now that I've opened a PR for this (#1574) , where I make it so that version ranges aren't supported on the CLi, I'm starting to bake my noodle on it more and wonder if we're taking the right path here.

To be specific, I'm starting to think that carets should _not_ be implicit in dep (#929), and that we should instead support ranges on the command line while defaulting to literal the version requested by the user on both the CLi and in the Gopkg.toml file.

My personal experience is that other package managers don't infer version ranges when you provide a bare version, and only use the version you specified. If you want to allow the manager to choose a newer version for you, the user should explicitly tell it with one of the many range operators.

Edit: I think if we are able to make guarantees that Semantic Version has been strictly followed, it's safe to implicitly have the caret. However, in practice there have been plenty of occasions where I've experienced going from one minor version to another introducing a breaking change.

The reason I am leaning this way is because of how I use dep when adding new things. Consider the following workflow:

• Determine that I need to use an external package for a feature
• Look at its available versions, and look for any open issues indicating a version is broken
• Select a version (or a range) that looks to be safe to use with the functionality I need
• Use dep ensure -add to add it to the project _before_ I import it.
• Start development of my feature, using the package version I specified on the CLi

Yes, I often go with the most-recent version because things are :+1:. However, there have been times where I've wanted to pin to an older version of the library because something I'm using doesn't support the newer version. I'd potentially want to add ~v1.2.3 because anything in 1.2 should be safe where 1.3.x isn't.

[caynan]

I agree with @theckman, it's usually better to be explicit than implicit especially with library versioning it's annoying to find out that your code is not working because your package manager decided to be smart about what you want. But that's just my 2cents