feature request: glide up takes an argument and only updates that package

[colemickens]

So, for example, glide up github.com/Azure/go-autorest would update the go-autorest dependency, without upgrading everything else in the glide.yaml file.

[mhoglan]

This is similar to what I was referring to in #249 ; Ability to separate the processing of imports, whether from glide.yaml or the project workspace.

There is an argument that could be made that if you version pinned things in a semantic versioning way, that it shouldn't matter if the latest of that version range was pulled in because it should be compatible. That is idealistic though, and reality is sometimes you want to just upgrade one dependency. Especially if your QA process requires verification of every dependency change for a release.

[mattfarina]

@colemickens There are two steps to an update in Glide. There are the direct dependencies of the local codebase and then there are the dependencies of the dependencies to form the tree. When we update a direct dependency the dependency tree needs to be re-resolved for any changes. This makes updating just a single dependency difficult. Or rather, it means to make it simple isn't so simple.

We used to have something sorta like this feature. I had not realized it was dropped. We should put something smart back. @technosophos is there a reason i don't know that we dropped this?

[atombender]

I'd like this, too.

It's annoying to find that glide up <some packagename> runs without complaining about the superfluous argument, but actually updates everything. What is the argument list used for?

[tcurdt]

There should be a glide up <some packagename> that updates only that dependency - plus the child dependencies.

[DallanQ]

I've gotten around this by removing the version number in the lock file for a package that I want to update more frequently than the others. Deleting the package files from the vendor directory followed by glide install updates the package to the latest version. This is not a great solution, but I haven't come up with a better way.

I agree it would really be nice to have glide up <some packagename>

[atombender]

@mattfarina Any update om this? It's truly annoying to have to undo changes to glide.lock when you only want to update a single dependency.

Sometimes I just give up and commit the whole file because I don't know the transitive relationships between packages. For example, if I add a new dependency X, and glide.lock now contains 3 new packages, I don't know if these are a result of adding X, or if a coworker had previously forgot to run glide when they added a different dependency.

[mattfarina]

@atombender it turns out this is more difficult than it seems when you default to versions and ranges. To do this you need to update the one dependency and then walk the tree to make sure the transitive dependencies are picked up and all the versions mesh.

Are you using versions or ranges in your glide.yaml file? I do so I don't tend to run into this problem as much as others do. That's why it's not been such a high priority with all the other requests coming in.

PRs are welcome.

[atombender]

Not using versions/ranges. I should be, of course, but I've been simply relying on glide get — it doesn't save the current version to glide.yaml (the way that npm i --save does), which I think is a mistake. Nor does it allow you specify a version constraint. Looks like I will have to add the versions manually. It's particularly awkward since glide get doesn't print the version it added to the lockfile either. Knowing the version ahead of time means having to go to the upstream git repo and peeking at what the current version is, as far as I can tell. This workflow could do with some improvement.

[sdboyer]

Similar things being discussed in #368

Nor does it allow you specify a version constraint.

Try specifying it with a trailing # instead of trailing @. e.g., github.com/foo/bar#1.0.0

it doesn't save the current version to glide.yaml (the way that npm i --save does), which I think is a mistake.

I agree, that would be a mistake...but are you using the most recent glide? Because glide get does save the version to glide.yaml for me.

Worth noting that this is one of the things that switching to the vsolver engine will address. (I almost wonder if we should have a tag for these)

[atombender]

@sdboyer Thanks, I didn't know about the hash syntax. If I use that syntax, it adds the version. Without the hash, it doesn't (I'm using 0.10.2). I would argue that it ought to add a version constraint (NPM uses ~>, which is a good choice) regardless.

Secondly, it raises the question of how to find the version in the first place. Right now, the workflow seems to require that I go to Github (or wherever), and look for a vX.Y tag. For gopkg.in packages, there seems to be a different system in use which I don't know, and which curiously enough doesn't use a v prefix (though at least the version number is shown on the web page):

[INFO] Detected semantic version. Setting version for github.com/jackc/pgx to v2.8.1.
[INFO] Detected semantic version. Setting version for gopkg.in/readline.v1 to 1.2.

(Where is this stuff documented?)

Perhaps there could be a flag to get the latest semantic version, or maybe something like glide get github.com/foo/bar#latest. This would put ~>1.5 or whatever into glide.yaml.

[colonelpanic8]

Is anyone working on this actively?

[sdboyer]

@IvanMalison AFAIK it's not being worked on in the current mainline branch, but it's basically solved in the new engine (#384).

(This specific thing is possible, but there's an underlying issue that cropped up which I'm working out before I can commit it.)

[sdboyer]

Just updating to note that, yes, this is one of the single most-requested bits of functionality in glide right now - and it is fixed in the new, gps-based version of glide, that we hope to be the next big release - v0.13.0.

There's still a fair bit of work between here and there, though; if you want to make it happen sooner, we could use your help! You can look at the project, or #565 in particular has a lot of individual items. Ping me (@sdboyer) in gitter or on slack if you think you may have some time, and there's nothing obvious to work on.