glide update one repo?

[tve]

I was expecting glide up <import path> to update just that import path, but it tries to update all dependencies. Is there a way to do only one?

[mattfarina]

As I think about this there are ideal and practical elements at work.

Ideally, Glide operates in a similar manner to NPM, Composer, Bundler, and the other package managers. In these cases you have a manifest file that describes the dependencies and the versions to use. Installing or updating sets up the dependencies with the specific versions and they are usually set with SemVer. This lets you manage the versions of dependencies in use well. This is how Glide was designed. For projects that don't specify a version and are using Git, which is the case for most packages, the tip of the default branch is the set version.

Practically speaking, most Go packages are not SemVer or versioned at all. This is problem enough there is a proposal to recommend projects start using SemVer in the Go proposal system.

If projects managing their dependencies are using these unversioned projects and vendoring their dependencies it makes sense they may only want to update one at a time. This only really makes sense if they are vendoring the dependencies, that is checking them into the local project repo. Outside of vendoring this becomes an issue because the next person to checkout the project and glide up will get the tip of all the projects rather than the same versions previously used by a different developer.

@tve I noticed you're not storing the vendor package in the repo on go-boilerplace. If you're only updating one package what's the use case for that? I'm trying to understand the use case and expectation you have.

Or, maybe there's a different angle I'm not thinking of. Can you enlighten me?

Thanks.

@technosophos I'm wondering about updating in the vendored use case. Would it be useful to have this in glide or as a plugin?

[technosophos]

I think @tve is right about expectations. Now that we are encouraging users to use glide get to get their dependencies (instead of downloading them by hand and then adding to glide.yaml), we should also allow single-package updates with glide up.

[tve]

Thanks for the thoughtful reply. There are 100 different motivations for vendoring (whatever that exactly means...) so I understand it's difficult to provide a tool that satisfies lots of users.

Our use-case expects a number of things from the package management:

• an easy way to install dependencies for CI
• the ability to check a dependency into the VCS when the dependency can't easily be fetched by CI due to permissions issues (private git repos)
• the ability to pin a dependency to a specific version, which may be a branch or a commit
• tools to verify where everything is coming from and whether there are newer versions

In terms of pinning versions, we like gopkg.in quite a bit. Some external dependencies use it and we trust the maintainer in general. For external dependencies that don't use gopkg.in we tend to go through a phase of rolling with it and then either fork the repo to control changes or pin to a branch or commit. For internal dependencies (i.e. repos we control) we tend to either use gopkg.in or pin to a branch eventually. We don't check a dependency into VCS unless it can't easily be fetched due to permissions or stuff like that, we don't check in to pin the version.

The bottom line is that there is a range of use-cases which depend on the nature of the dependency and there is a long development phase where things are not pinned to a version.

The situation that prompted my ticket was that I repeatedly made changes to a dependency that I maintain and wanted to bring the changes into my project but didn't want to wait for all other dependencies to be checked nor did I really want a disruption if any of them had changed.

Something else I've been missing is a -dryrun flag for update: tell me what you'd update and why, but don't do it.

Thanks much!!!

[technosophos]

Can we open a separate ticket for -dryrun?

[technosophos]

I've added support for the ticketed feature. You can now do: glide update foo

You can also do glide update foo bar baz and have all three updated. This brings glide up into line with the new glide get feature.

I'm opening a new ticket for -dryrun. Did I miss anything?

[marians]

I just found out about this function by googling, ending up here in this issue.

Is there a good reason this isn't documented? At least I couldn't find any hint or examples.

Also, it seems as if glide goes through all dependencies although I am calling it like glide update --strip-vendor github.com/org/repo. Is that expected behaviour? If not, I will gladly open an issue with more details.

[dimonomid]

So why is this issue closed? glide update github.com/org/repo still updates everything, not just github.com/org/repo.

[khogeland]

Promised feature doesn't seem to exist, wontfix with zero explanation

:clap:

[dimonomid]

Masterminds can afford that. :)

That all looks funny, and glide is surprisingly broken (especially for something with 7K stars on github), but jokes aside, it's already time to move to Go modules.

[zplzpl]

pity function