New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
colemickens opened this Issue Feb 12, 2016 · 13 comments

Comments

Projects
None yet
8 participants
@colemickens
Copy link

colemickens commented Feb 12, 2016

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 comment has been minimized.

Copy link
Contributor

mhoglan commented Feb 15, 2016

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

This comment has been minimized.

Copy link
Member

mattfarina commented Feb 16, 2016

@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

This comment has been minimized.

Copy link
Contributor

atombender commented Mar 1, 2016

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

This comment has been minimized.

Copy link

tcurdt commented Mar 10, 2016

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

@DallanQ

This comment has been minimized.

Copy link

DallanQ commented Apr 1, 2016

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

This comment has been minimized.

Copy link
Contributor

atombender commented Apr 11, 2016

@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

This comment has been minimized.

Copy link
Member

mattfarina commented Apr 11, 2016

@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

This comment has been minimized.

Copy link
Contributor

atombender commented Apr 11, 2016

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

This comment has been minimized.

Copy link
Member

sdboyer commented Apr 11, 2016

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

This comment has been minimized.

Copy link
Contributor

atombender commented Apr 11, 2016

@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.

@IvanMalison

This comment has been minimized.

Copy link

IvanMalison commented May 11, 2016

Is anyone working on this actively?

@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented May 11, 2016

@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 sdboyer referenced this issue May 18, 2016

Closed

Initial integration of gps into glide #384

4 of 8 tasks complete

ches added a commit to go-kafka/connect that referenced this issue Aug 3, 2016

Vendor protobuf as test dependency for Gomega ghttp
I’m not really happy that this is foisted on me.

onsi/gomega#123

I can also no longer get `glide install` after adding one new dep
to `glide.yaml` by hand to stop updating SHAs for everything, I give up:

Masterminds/glide#252

This should all hopefully eventually get fixed by Masterminds/glide#384
@sdboyer

This comment has been minimized.

Copy link
Member

sdboyer commented Oct 17, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment