Skip to content
This repository has been archived by the owner on Feb 24, 2020. It is now read-only.

*: replaced godep with glide #186

Closed
wants to merge 0 commits into from
Closed

Conversation

cgonyeo
Copy link
Member

@cgonyeo cgonyeo commented Feb 26, 2016

Godep was continually being a drain on development resources of acbuild,
and thus this commit replaces godep with glide. Glide takes advantage of
the golang vendor experiment, and thus this change will drop support for
versions of Go less than 1.5.

The biggest impact this change has is that dependencies are no longer
vendored with acbuild, and are instead fetched at compile time by the
build script. This is done by checking if the vendor directory exists,
and running glide install if it is not.

Fixes #98. Replaces #157.

@cgonyeo cgonyeo force-pushed the no-more-godep branch 2 times, most recently from 0a5481e to e3cb044 Compare February 26, 2016 20:26
@jonboulle
Copy link
Contributor

Why do you not want to vendor the deps?

Derek Gonyeo [email protected] schrieb am Fr., 26. Feb. 2016 20:23:

Godep was continually being a drain on development resources of acbuild,
and thus this commit replaces godep with glide. Glide takes advantage of
the golang vendor experiment, and thus this change will drop support for
versions of Go less than 1.5.

The biggest impact this change has is that dependencies are no longer
vendored with acbuild, and are instead fetched at compile time by the
build script. This is done by checking if the vendor directory exists,
and running glide install if it is not.

Fixes #98 #98. Replaces #157

#157.

You can view, comment on, or merge this pull request online at:

#186
Commit Summary

  • *: replaced godep with glide

File Changes

Patch Links:


Reply to this email directly or view it on GitHub
#186.

@cgonyeo
Copy link
Member Author

cgonyeo commented Feb 26, 2016

It's not something that's as nicely supported with glide. It leaves the .git directories in what it fetches, and I didn't see an easy way to disable that.

I see two arguments to not want to move away from vendoring our dependencies:

  • What if one of our dependencies vanishes from github?
    • We have a local copy on our machines (because it'll be sitting in acbuild's vendor directory), and can throw up a fork of the project.
  • What if github goes down?
    • This will only impact users who haven't yet built acbuild once, and chances are if someone who wants to build acbuild is at this stage then they don't have acbuild either, and won't be able to get it anyway.

I also think that glide's model will make it a good amount easier to work on both acbuild and one of acbuild's dependencies concurrently, since you can just cd into vendor/github.com/the/dependency, make changes, see the impact on acbuild, and when you're done commit and push inside the vendored repo.

@cgonyeo cgonyeo force-pushed the no-more-godep branch 2 times, most recently from 3c87949 to e049a6a Compare February 26, 2016 21:40
@sgotti
Copy link
Member

sgotti commented Mar 3, 2016

Hi, as I also started experimenting with glide, I'd like to share what I learned since I'd prefer to vendor dependencies:

  • Glide doesn't remove .git and other VCS directories. But you can easily do this and now there's a tool to do this:

http://engineeredweb.com/blog/2016/glide-strip-vendor-vcs/

  • Glide doesn't remove unused packages so the created vendor, also with VCS data stripped out, remains with unneeded files (for example importing just the etcd client package imports the whole etcd project). The explanation is related to licensing and project modifications:

http://engineeredweb.com/blog/2016/go-why-not-strip-unused-pkgs/

But if you are sure of not causing license issues you can probably write a tool (I'm going to do this if it doesn't exists) that, given the glide.lock will remove all the files outside the import or subpackages (if the import have sub packages).

  • Just for completeness (but it's a general info and not related to glide) as the glide faq says, vendoring is good for the final application but with a package meant to be used by other projects it can cause problems in some cases:
    https://github.com/mattfarina/golang-broken-vendor

But this is a problem present also with old style Godep vendoring/rewriting.

@jonboulle
Copy link
Contributor

@sgotti thanks for letting us know your experience! Would you mind sharing
more about why you wanted to move away from Godep and how glide improves?

On Thu, Mar 3, 2016 at 9:46 PM, Simone Gotti [email protected]
wrote:

Hi, as I also started experimenting with glide and I'd like to share what
I learned since I'd prefer to vendor dependencies:

  • Glide doesn't remove .git and other VCS directories. But you can
    easily do this and now there's a tool to do this:

http://engineeredweb.com/blog/2016/glide-strip-vendor-vcs/

  • Glide doesn't remove unused packages so the created vendor, also
    with VCS data stripped out, remains with unneeded files (for example
    importing just the etcd client package imports the whole etcd project). The
    explanation is related to licensing and project modifications:

http://engineeredweb.com/blog/2016/go-why-not-strip-unused-pkgs/

But if you are sure of not causing license issues you can probably write a
tool (I'm going to do this if it doesn't exists) that, given the glide.lock
will remove all the files outside the import or subpackages (if the import
have sub packages).

  • Just for completeness (but it's a general info and not related to
    glide) as the glide faq says, vendoring is good for the final application
    but with a package meant to be used by other projects it can cause problems
    in some cases: https://github.com/mattfarina/golang-broken-vendor

But this is a problem present also with old style Godep
vendoring/rewriting.


Reply to this email directly or view it on GitHub
#186 (comment).

@sgotti
Copy link
Member

sgotti commented Mar 8, 2016

@jonboulle sure. I'm currently not in the position to suggest a tool over another. I was intrigued on how it tries to manage dependencies like npm, pip, bundler using a config file and lock files, it tries to implements semver dependencies and read config from other vendor tools like godeps, gb etc...

Obviously, since golang is really distributed and doesn't have a central repository, there are some differences with other languages/tools.

One interesting thing is that it doesn't needs packages in your gopath but it will check them out directly inside your project (or copy them from a cache dir or from the gopath and then checking out the right version inside you project).

On the other side, glide doesn't enforce you to commit your vendor directory. This is causing me some headache since many projects (myself too) wants to commit it (for a lot of good reasons), but having or not having nested vendor directories have a different compilation behavior. I opened Masterminds/glide#303 to talk about this.

Additionally, if I want to commit, and I'm sure to not cause licenses violations, I'd like to remove as much as possible from the vendor directory. I wrote a tool to do this (https://github.com/sgotti/glide-vc) (with some changes in flight, see the opened PRs)

@sgotti
Copy link
Member

sgotti commented Mar 31, 2016

After triggering some discussions on Masterminds/glide#303, glide 0.10 has much improved the vendor handling (http://engineeredweb.com/blog/2016/glide-0.10.0/)

Now you can easily remove nested vendor folders. This obviously means that you won't have problems like this but you can't have multiple versions of the same package (since all deps are flattened). So if you have two dependencies that depends on incompatible version of pkgA you have to find a fix for making them work together.

actually my preferred workflow is this one:

  • create a glide.yaml (glide create, if already using godeps it'll convert them from godeps)
  • Update it (I prefer to specificy semvers tagged releases when possibile)
  • rm -rf vendor (I like to treat my vendor as scratch dir and be able to recreate it every time)
  • glide update -u -s -v --cache # This will populate the vendor dir, remove VCS data and strip vendor (also undo godeps import rewriting). --cache is very useful to avoid git cloning deps every time I run it, you can also use --cache-gopath and --use-gopath instead of having a dedicated cache dir (under ~/.glide.
  • Test, fix glide.yaml for incompatibilities (for example force subdependency versions if needed)
  • Before committing glide.yaml, glide.lock and vendor/, super strip vendor/ removing (if licenses will permit it) all unneeded files using glide-vc (https://github.com/sgotti/glide-vc):
    glide-vc --only-go --no-tests

@jonboulle
Copy link
Contributor

cross-linking sorintlab/stolon#131

@cgonyeo cgonyeo force-pushed the no-more-godep branch 3 times, most recently from f89dcb5 to b06b19a Compare June 13, 2016 23:48
@cgonyeo
Copy link
Member Author

cgonyeo commented Jun 13, 2016

Revisited this, tests now pass. Now vendors dependencies, unlike when I originally made this PR (uses glide flags to trip VCS info). Added Documentation/development-guide.md with a short guide on using glide.

@cgonyeo
Copy link
Member Author

cgonyeo commented Jun 14, 2016

Oh, and due to switching to using vendor, this commit drops go 1.4 from the travis tests.

@jonboulle
Copy link
Contributor

@dgonyeo there is a tonne of unused stuff in there - is this post-glide-vc?

@cgonyeo cgonyeo force-pushed the no-more-godep branch 2 times, most recently from bd14fc4 to d47261f Compare June 14, 2016 18:20
@cgonyeo
Copy link
Member Author

cgonyeo commented Jun 14, 2016

No it's not. Just ran glide-vc, updated the docs to state that it should be used and how to use it, and added these changes to the PR.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants