tools

godep

Go2013–2018

tools / godep · Archived

godep

dependency tool for go

Explore on GitHub Read Hacker News discussions

25Distinct people

28Mentions

0Explicit recommenders

5.5KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

dependency tool for go

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

golang/dep · linked in 2 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year28 dated mentions

Observed mentions: 2013-10-29 10:14:57 UTC to 2018-03-26 16:39:25 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2013	2013-01-01 00:00:00 UTC	2014-01-01 00:00:00 UTC	2	2
2014	2014-01-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	11	11
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	9	9
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	3	3
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	2	2
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	1	1

What Hacker News says

28 sources

benesch·Mar 26, 2018

The constant thrash caused by the lack of a standard package management tool—even a de facto standard. Just look at the various package managers that have come and gone over the years: 1. https://github.com/tools/godep 2. https://github.com/kardianos/govendor 3. https://github.com/robfig/glock 4. https://github.com/rogpeppe/govers 5. https://github.com/Masterminds/glide 6. https://github.com/golang/dep I'm sure I'm forgetting a few. And just when it seemed the Go team might be ready to standardize around Dep (6), they threw this wrench in the works. I'm of two minds about vgo. I think it has some interesting ideas, but Dep works today, is widely adopted, and has nearly all the features you'd expect from a modern package manager.

In A Proposal for Package Versioning in Go

naibafo·Sep 22, 2017

First a note, godep is a different tool then the one you mean [1], that does the same. > dep still has nasty bugs, but in general these are comparable or fewer to other tools out there. (From the Github readme) I started a project about two months ago and wanted to use Dep, however there were a few show stopping issues for that. Most prominently Go has issues with upppercase/lowercase repositories, meaning if one of your dependencies imports github.com/Sirupsen/logrus, and you or another dependency imports github.com/sirupsen/logrus your code won't compile, no matter if you are on a case sensitive system or a case-insensitive system. [2] The aforementioned logger made a switch in the naming which caused problems while most were migrating the import. The docker distribution in its latest stable version still uses uppercase, while others us

Read the rest

e the lowercase. Dep follows the Go specifications and at the moment just throws an error, before, they didn't handle it at all. So I had to resort to a different dependency management for now, which did some linking to fix the situation. [1]https://github.com/tools/godep [2]https://github.com/golang/dep/issues/1010

In Go: Ten years and climbing

rexf·Jul 13, 2017

there is the godep tool that addresses the issue https://github.com/tools/godep > godep helps build packages reproducibly by fixing their dependencies

In Toward Go 2

jzelinskie·Mar 4, 2016

I have a single $GOPATH per project and always recommend doing so. If you vendor code with a tool like godep[0], having one shared $GOPATH is a nightmare. Other tools might work better, but this is basically the standard for the projects I work on. I basically just have a zsh alias[1] that combines z[2] and sets the $GOPATH to $PWD split on "src". I do share a single $GOBIN set to $HOME/bin, though. [0]: https://github.com/tools/godep [1]: https://github.com/jzelinskie/dotfiles/blob/04ad026f30782189... [2]: https://github.com/rupa/z

In Visual Studio Code for Go

ihsw·Jan 26, 2016

It does kick the can down the road, but it kicks it pretty far. I'm not the parent but your question is completely valid -- trying to get dependencies of dependencies sends us down a very deep rabbit hole. This is usually where dynamic linking and shrinkwrapping[1]/vendoring[2] start entering serious discussions. [1] http://blog.goguardian.com/nerds/shrinkwrap-not-just-for-mur... [2] https://github.com/tools/godep

In Code.google.com was shut down, Go packaging is broken

cfstras·Jan 26, 2016

https://github.com/tools/godep should solve all these issues. Yes, it vendors packages. But it happens completely automatically and you can switch to your own forks at will.

In Code.google.com was shut down, Go packaging is broken

namecast·May 7, 2015

I've been using Godeps, which feels like a close equivalent - have a gander and see if it's useful: https://github.com/tools/godep Semver support was what got me using godep and I haven't looked back since (at least for larger projects).

In Problems with Go Get

jzelinskie·May 2, 2015

If you're going to make another tool like this, you _need_ to make it immediately obvious about how it improves on the experience provided by godep[0] which has basically become the standard tool for dependency management in Go. [0]: https://github.com/tools/godep

In Gigo: Pip for Go

drewolson·Apr 29, 2015

How is this different from godep[1] other than being the root of its own GOPATH and having a different naming convention for the location of vendored dependencies? [1] - https://github.com/tools/godep

In Reproducible Builds in Go

ghodss·Apr 29, 2015

One major limitation of this approach is that any project that wishes to vendor or lock their dependencies can no longer be used as a dependency for another project. From the gb GitHub: > A project is the consumer of your own source code, and possibly dependencies that your code consumes; nothing consumes the code from a project. This seems to imply that any code outside of a project (i.e. the code inside vendor/src) has no recourse for indicating the versions of their dependencies. This is nice in that it simplifies the problem, but to completely remove the ability for any and all libraries to indicate the versions of their dependencies seems unnecessarily restrictive. If I build a library for others to use, and I have a dependency, I want to be be able to lock to a specific version, or at least give my preference for a version. Of cours

Read the rest

e, this creates its own issues - what do you do when two libraries depend on two different versions of the same library? (Also known as the diamond dependency problem.) This is where the Go culture helps, where as long as you pick a later version, things are likely to work. But I'd rather have the tooling let me detect the two versions that the two libraries want, show that there is a mismatch, and give me the ability to override and pick one (probably the later one). Instead, the gb approach eliminates the ability for the libraries to even have the ability to indicate what version they would prefer, which makes it even more difficult to get a bunch of libraries that share dependencies to work correctly together. godep (https://github.com/tools/godep) seems to have the best compromise: vendor dependencies without path rewriting (though with GOPATH rewriting), but also keep track of their versions in a Godep.json file. You can gracefully pick between conflicting versions upstream if need be.

In Reproducible Builds in Go

stock_toaster·Mar 3, 2015

I don't believe so. Your options are still pretty much: (a) vendoring with something like godep[1], or (b) point in time scm fetching with something like gpm[2]. [1]: https://github.com/tools/godep [2]: https://github.com/pote/gpm

In Cross compilation just got better in Go 1.5

bbrazil·Feb 25, 2015

https://github.com/tools/godep/blob/master/Readme.md explains it. It's not really a package manager, though you can get some of the same results. It's more pulling in exact build dependencies.

In Stages of learning Go, with code examples

NateDad·Feb 11, 2015

Man, that page needs a "What is Nexus?" link. I can't really tell what it is.. I guess some sort of central repo for packages? What go has is Godep (https://github.com/tools/godep) which with a single command can copy all your project's dependencies into your repo. from there on out, the dependencies are just part of source control like anything else, so you don't have to open up your build machine to the external internet, for example.

In Go kit: Go in the modern enterprise

wiremine·Jan 29, 2015

I'e been writing my first production-sized Go app over the last few months, and really enjoy it. Some observations: - The standard library is solid, and I was surprised how well-rounded and mature the third-party library support it. Coming from a Python/Ruby background, that was nice to see. - I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see a canonical dep management tool for go. - The tooling for Go is excellent: More languages need something like "go fmt". - In general the document is solid, but I've found the usability of the generated docs to be poor. You think they could bribe a few Google designers to spend some time fixing that... - I've noticed a lot of Rust lovers commenting about how great Rust's type system is. It probably is, but I haven't run into a

Read the rest

ny problems with Go's type system. I've found it to be practical and easy to use. The only issue is parsing JSON when you're not marshalling it to struct. They need to fix that (although there are some nice third-party tools to make it easier). - Go is a minimal language and has been called boring. [2] I don't claim to be an expert yet, but I don't think I've reached this level of productivity with a language this quickly before. [1] https://github.com/tools/godep [2] http://stevebate.silvrback.com/go-is-boring

In From Node.js to Go

bacongobbler·Jan 2, 2015

This is mainly due to the current issues in Go with how package imports are handled. Since the Go port of hub relies on third party libraries, it uses Godep[1] to vendor its dependencies. With /Godeps: 44838 LOC Without /Godeps: 14733 LOC [1]: https://github.com/tools/godep

In GitHub's “hub” tool rewritten in Golang

Showing the 15 most recent of 28 sources. Enable JavaScript to search and browse every indexed mention.