Barebones dependency manager for Go.


Go Package Manager Build Status

Go Package Manager (or gpm, for short) is a tool that helps achieve reproducible builds for Go applications by specifying the revision of each external Go package that the application depends on.

Being simple and unobstrusive are some of the most important design choices for gpm: go get already provides a way to fetch dependencies, and relies on versions control systems like Git to do it, gpm adds the additional step of setting each dependency repo to the desired revision, neither Go or your application even know about any of this happening, it just works.

To achieve this, gpm uses a manifest file which is assumed to be called Godeps (although you can name it however you want), running gpm fetches all dependencies and ensures each is set to a specified version, down to revision level.

Basic usage

For a given project, running gpm in the directory containing the Godeps file is enough to make sure dependencies in the file are fetched and set to the correct revision.

However, if you share your GOPATH with other projects running gpm each time can get old, my solution for that is to isolate dependencies by manipulating the GOPATH, see the workspaces section for details.

You can see gpm in action under this workflow in the following gif:

sample gpm usage

Installation options

In OSX with Homebrew

$ brew install gpm

In Arch Linux - AUR

$ yaourt -S go-gpm


$ packer -S go-gpm

Caveat: you'll use go-gpm instead of just gpm in the command line, as there is a general purpose linux package under that name already.

Manually with a one-liner

Latest stable release:

$ wget && chmod +x gpm && sudo mv gpm /usr/local/bin

Manually on *nix using the makefile.

$ git clone && cd gpm
$ git checkout v1.4.0 # You can ignore this part if you want to install HEAD.
$ ./configure
$ make install

Use directly from GitHub

As gpm is a bash script you can always use it directly from GitHub via wget or curl, this is particularly useful for CI servers and other automated environments.

## With wget
$ wget -qO- | bash

## With cURL
$ curl -s | bash

The Godeps file

gpm expects you to have a file called Godeps in the root of your Go application in the format <import path> <tag/revision>.

Once this file is in place, running the gpm tool will download those packages and check out the specified versions.


You can specify packages with the <import path> <version> format, where version can be a revision number (a git/bazaar/mercurial/svn revision hash) or a tag.

$ ls .
Godeps  foo.go  foo_test.go

$ cat Godeps               v0.0.2         v1.02                     r2013.03.03   # Bazaar repositories are supported    ae081cd1d6cc  # And so are Mercurial ones

When specifying your dependencies please keep in mind how gpm and the go tool operate: importing a package is setting the version of a cloned repo to a specific revision, so if you are importing several subpackages that are hosted under the same repo only one of them (the top level) should be specified in your Godeps file, in cases where there are no Go packages in the root of the dependency repository you can get Go to fetch the code anyway by appending /... to the import path (see last line in the example above)


The Godeps file accepts comments using a # symbol. Everything to the right of a # will be ignored by gpm, as well as empty lines.


As a convention comments can be used to specify lines that gpm core should ignore but are instead intended to affect how a given gpm plugin behaves.

For example: a hypothetical gpm-track plugin that makes sure a given package is always updated to its last possible version would leverage a line like this one:


This convention makes the Godeps file format extensible, just as with plugins this can help identify common needs that might later on be merged into core without having to sacrifice code simplicity in order to explore new features.

Private Repos

Both gpm and go get support using private GitHub repositories! Here's what you need to do in order for a specific machine to be able to access them:

  • Generate a GitHub access token by following these instructions.
  • Add the following line to the ~/.netrc file in your home directory.
machine login <token>

You can now use gpm (and go get) to install private repositories to which your user has access! :)


Any dependency not specified in the Godeps file will be installed by the Go tool to whatever revision the master branch of its hosting repository is pointing at that given moment, as reproducibility is the main goal of gpm it is suggested to be exhaustive and list all your dependencies in the file, with a specific revision.

Do it once, reproduce it anytime, it pays off.


gpm has the following commands:

$ gpm             # Same as 'install'.
$ gpm get         # Parses the Godeps file, gets dependencies and sets them
                  # to the appropriate version but does not install them.
$ gpm install     # Parses the Godeps file, installs dependencies and sets
                  # them to the appropriate version.
$ gpm version     # Outputs version information
$ gpm help        # Prints this message


As of version v1.1.1 gpm supports plugins, the intent of which is the ability to add powerful non-core features to gpm without compromising the simplicity of its codebase.

The way gpm plugin works is simple: whenever an unknown command is passed into gpm it will look for an executable in your $PATH called gpm-<command> and if it exists it will run it while passing all extra arguments to it, simple yet powerful.

This brings a lot to the table: plugins can be written in anything, they can be Go binaries, bash scripts, Ruby gems, Python packages, you name it. gpm wants to make it easy for you to extend it. :)

Installing plugins through Homebrew

I maintain a repository with homebrew formulae for gpm plugins that you can add to your system with the brew tap command:

$ brew tap pote/gpm_plugins

After you've done this you can install plugins as you would with any other homebrew packge.

$ brew install gpm-bootstrap

Known Plugins

If you have written a gpm plugin and want it included please send a pull request to the repo! I love how people have taken to explore possible features using plugins so if you've written one there is about a 99% chance I will include it here. :)

Name and Link Author Short Description Type
gpm-bootstrap pote Creates an initial Godeps file official
gpm-git technosophos Git management helpers third party
gpm-link elcuervo Dependency vendoring third party
gpm-local technosophos Usage of local paths for packages third party
gpm-prebuild technosophos Improves building performance third party
gpm-all pote Installs multiple sets of deps official
gpm-lock zeeyang Lock down dependency versions third party

There is no real difference on official/third party plugins other than the willingness of the gpm core team to support each, plugins labeled as third party will be supported (or not) by their authors.


A question that comes up time and time again is how to handle different workspaces for Go projects.

This question has many answers, and gpm should be compatible with most of them. My personal way to solve it is to have an environment file per project, which I use to manipulate the GOPATH whenever I switch to a given project.

$ cd my_project
$ cat .env
export GOPATH="$PWD"/.dependencies:"$PWD"
$ source .env

After sourcing the env file (in which I usually keep other project-specific configuration variables, like database urls, secret keys, etc) the active GOPATH is a local one: this means that I don't need to run gpm again to make sure my dependencies are in the correct version and there is no danger of conflicting dependency versions across different projects. Everything is isolated and can be easily wiped clean if needed.

Further Reading

The creator for the gpm-git and gpm-local and an alternative package manager called Glide wrote a fantastic blog post explaining the usage and rationale of gpm, it sums up explanations for several of the design decisions behind both tools.


Lots of people have contributed to make gpm what it is today, if you want to take your time to play around with the code please do so! Opening issues on bugs, feature requests or simple food for thought are a great way to contribute, if you send a pull request please be a good citizen and do things in a tidy manner.

  • Create a feature branch with a meaningful name.
  • Make sure your commit messages and PR comments are informative.
  • Write a test for your feature if applicable.
  • Always remember to run the test suite with make test before comitting.

Either way, thank you very much for any form of contribution, even if a patch ends up not being merged the fact that it was sent and forced us to think about it is a contribution in itself.


Released under MIT License, check LICENSE file for details.


This tool is inspired by Ruby's dep gem - authored by @cyx and @soveran, big thanks to them and to all the contributions made by the many wonderful people in our contributors page.

gpm is maintained by @pote and @elcuervo.

  • Error sometimes with `gpm install` on existing projects

    Error sometimes with `gpm install` on existing projects

    I just noticed this a few times today. It looks like sometimes a race condition happens:

    >> Setting to version
    # cd /Users/mbutcher/Code/Go/src/; git checkout master
    fatal: Unable to create '/Users/mbutcher/Code/Go/src/': File exists.
    If no other git process is currently running, this probably means a
    git process crashed in this repository earlier. Make sure no other git
    process is running and remove the file manually to continue.
        imports exit status 128

    I am having trouble reproducing this, but every once in a while I see the same error (on different projects each time).

    opened by technosophos 15
  • Doesn't set revision when using subpackage of repository

    Doesn't set revision when using subpackage of repository

    For example, if my Godeps file looks like c9f216d

    the namesgenerator package will still be at master since that directory doesn't contain a .git folder. gpm should traverse through the parent directories of the package until it find a version control system indicator, or fail if one doesn't exist.

    opened by ligfx 12
  • Dependency binaries not building?

    Dependency binaries not building?

    I have a project with a dependency on, but when gpm installs the dependency the goconvey binary is not built. On the flipside, if you use go get the binary is created without issue.

    So, with that said, is this intentional? And if so, is there a trick to getting the binary created as part of the gpm dependency resolution process?

    opened by leeola 10
  • Git Updating: Branches vs. Tags/Commits

    Git Updating: Branches vs. Tags/Commits

    I've been struggling with using GPM for trees that I want to keep updated to the latest commit on a particular branch.

    Use case:

    I want a repository to stay on the latest checkout on master, and each time I run gpm install I want it to update to the latest commit

    If my Godeps file looks like this:

    Then master is checked out initially, and the tree is updated each time gpm install is run, but the repo is always pointed to whatever commit I got when I initially ran gpm install.

    Same thing happens if I do this:

    The relevant line in GPM is this:

    I had the same problem a while ago with gpm-git, and ended up doing this:

          # Figure out, based on ref, what type of reference this is.
          local vtype="commit"
          git show-ref -q "origin/$version" && vtype="branch"
          git show-ref -q "tags/$version" && vtype="tag"
          echo ">> Setting $package to $vtype $version"
          cd $install_path
          [ -d .git ] && git checkout -q "$version"
          # Handle case where branch changed. We need to get to the tip
          # of that branch.
          [ $vtype == "branch" ] && git merge --ff-only origin $version

    It's far more verbose, but it seems to do the trick.

    If I have the time this week, I will work up a patch and submit a pull request. Feel free, of course, to find a better way of doing it (or to simply say that this is out of scope for GPM).

    As always, thanks for a great tool.

    opened by technosophos 10
  • Consider adding GO15VENDOREXPERIMENT support

    Consider adding GO15VENDOREXPERIMENT support

    In 1.5 the go command will read the environment variable GO15VENDOREXPERIMENT. If enabled, it will use the local "/vendor/" folder for dependencies. This replaces the need to manage GOPATH variables as dependencies can be fetched directly into the vendor folder and resolved there when built. This allows the GOPATH to not be modified. The contents of the vendor folder can be ignored.

    Will you consider supporting this approach?

    opened by kardianos 9
  • Updates gpm script to support cloning private repos

    Updates gpm script to support cloning private repos

    Go's 'go get' functionality lacks support for cloning private repositories via SSH. This commit extends the core 'gpm' script to bootstrap cloning of private repositories.

    The core change is to suppot an additional '.git' suffix for import paths in the Godeps file. If this suffix is present AND the package does not already exist in GOPATH, 'git clone' will be run to pull down the initial copy of the repo (instead of the standard 'go get -u -d'). Subsequent invocations of gpm will still use the defined checkout command for each VCS gpm supports.

    opened by lamielle 9
  • Support other VCSs

    Support other VCSs

    Some users have made public their interest in adding bazaar support, I'm opening this issue as a discussion forum for this and other VCSs we might want to add support to.

    Do you want us to support svn? mercurial? bazaar? please state so in here and we'll plan our roadmap accordingly to the interest show on each. :)

    opened by pote 9
  • Easier installation and plugin management

    Easier installation and plugin management

    In my opinion, gpm is being too reliant on home-brew for distributing itself to users. If gpm is rewritten in go, we can distribute it easily as a binary. And also a lot of other features can be added easily.

    I am pledging my time to do this alongside with you.

    opened by pksunkara 7
  • Extensions to the Godeps file format?

    Extensions to the Godeps file format?

    I'd love to see some extensions to the Godeps format that can accomodate specifying the repository (à la technosophos/gpm-git) and the name of the local package (à la elcuervo/gpm-link and technosophos/gpm-local).

    It'd also be cool to support versioning ranges (e.g. in this major version, after this minor version, stable releases after this revision, etc.), though I haven't seen anyone do that yet. Just thinking about the future :)

    Here's an idea I was kicking around:

    # My name is Godeps-ng
    # Local package is specified with a dot. Looks similar to Go's format for
    # importing a package into the local namespace
    # Simple dependencies are as before 71e406b
    # Specify repository URI, like gpm-git. I include the extra part after the
    # colon to indicate where in the repository the package exists, which
    # looks similar to the syntax for the `scp` command and probably
    # wouldn't mess up any VCS URIs. c9f216d \

    Thoughts @pote @technosophos @elcuervo anyone else?

    opened by ligfx 7
  • I am currently using gpm in part of deployment

    I am currently using gpm in part of deployment

    I am currently using gpm in part of deployment for my go projects. I have my ci building out binaries before every push.

    I often see errors like so

    >> Getting package
    # cd /Users/myusuf3/go/src/; git pull --ff-only
    error: Ref refs/remotes/origin/master is at efcaa340c1a788c79e1ca31217d66aa41c405a51 but expected deb4a5e3b15dea23f340a311eea995421845c356
    error: Cannot lock the ref 'refs/remotes/origin/master'.
     ! deb4a5e..efcaa34  master     -> origin/master  (unable to update local ref)
        imports exit status 1
    # cd /Users/myusuf3/go/src/; git pull --ff-only
    fatal: unable to access '': Server aborted the SSL handshake
    package exit status 1
    # cd /Users/myusuf3/go/src/; git pull --ff-only
    fatal: unable to access '': Server aborted the SSL handshake
        imports exit status 1
    # cd /Users/myusuf3/go/src/; git pull --ff-only
    fatal: unable to access '': Server aborted the SSL handshake
        imports exit status 1

    I need for the gpm to go smoothly and only exit 1 on actual failure ( it continues fine after that, but ci fails due to non zero exit value) and i am unable to understand issue clearly some ideas to help would awesome

    opened by myusuf3 6
  • Dev vs Production Deps?

    Dev vs Production Deps?

    gpm supports custom Godeps naming, so you can have Godeps and (or whatever), but is there any desire to see this integrated tighter? Perhaps in a single Godeps file, you could define production / development deps? v1 v2

    I dislike adding complexity to the simple Godeps, but i also feel a standardized way to handle devdeps would be handy.

    opened by leeola 5
  • Compatibility with future Go versions

    Compatibility with future Go versions

    Just a heads up that Go 1.17 (and the just-released 1.16 without first changing GO111MODULE) won't support builds that aren't in module-aware mode.

    I'm not sure what the status of this project is. Is there any plans to migrate to Go modules?

    opened by carlocab 0
  • git: You are not currently on a branch

    git: You are not currently on a branch

    I found gpm and wanted to give it a try. It looks like it does not support pinning dependencies based on commits. I have this in my Godeps file.               bb985e34f0942b1d770bf96e87f830cf38804abe

    This is what I get.

    # cd /path/to/workspace/src/; git pull --ff-only
    You are not currently on a branch.
    Please specify which branch you want to merge with.
    See git-pull(1) for details.
        git pull <remote> <branch>
    package exit status 1

    Is this intended? Can we make it work?

    opened by xh3b4sd 3
  • Rewrite test suite with BATS

    Rewrite test suite with BATS

    We currently use an assert script that somebody wrote and a custom script to execute all tests, it's kind of messy, I'd prefer if we had something more polished, enter BATS

    I'll do this at some point if I have the time and the drive, if not I welcome anyone who wants to take a crack at doing it!

    opened by pote 0
  • Errors from git commands when a pkg and its sub-pkg is in Godeps

    Errors from git commands when a pkg and its sub-pkg is in Godeps

    We have a case where we need the top-level pkg of a given Go pkg for use in our application and also one of its sub-pkgs b/c it's a CLI. It seems gpm produces errors in output because it tries to git checkout the sub-pkg even though it's not a submodule but just a sub-directory in the parent pkg.

    Fortunately, gpm seems to still work as the binary gets installed in $GOPATH/bin; however, it'd be nice if we could avoid or suppress errors in output from gpm to avoid confusion.

    You can see a basic Godeps file here along with the errors from running gpm:

    Also, I set $GOPATH and $GOBIN to a temporary directory for the test above and, again, the binary was installed along w/ the pkg.

    Potential workarounds:

    • Do not issue vcs checkout commands if it's a sub-pkg and it's not a submodule (or equivalent).
    • Add a comment in the version placeholder to designate no checkout whereby the vcs will not attempt to checkout the sub-pkg.
    • Punt and instruct users to move the sub-pkg to a Makefile or other build script using go get after a gpm run.

    I don't know if any of these ideas are good but maybe something sparks.

    opened by jpfuentes2 0
  • Add support to list outdated dependencies in the Godeps file

    Add support to list outdated dependencies in the Godeps file

    Something along the lines of bundle outdated that ruby has but for go. This would help a lot in terms of keeping up to date with the latest versions when using version constraints in the Godeps file.

    opened by thomasdziedzic 1
  • Path names are not escaped

    Path names are not escaped

    If the path to gpm's working directory contains white spaces, I see the following errors:

    >> Setting to version 
    /usr/local/bin/gpm: line 66: cd: /Users/codewerft/Codewerft/Kunden/03: No such file or directory
    /usr/local/bin/gpm: line 66: cd: /Users/codewerft/Codewerft/Kunden/03: No such file or directory

    The working directory in the case above was /Users/codewerft/Codewerft/Kunden/03 - XYZ/Entwicklung/reactor.backend.

    opened by oweidner 1
  • v1.4.0(Jan 20, 2016)

    Howdy everyone!

    For a while, gpm has had gpm get thanks to contributions from @pe-vsn and nice cleanup from @foca, I think it's past time a new release is made to include the new command, and to make it the default action.

    The rationale for this is that gpm install is greedier in it's attempt to not only get the dependency code and set it to the correct version, but also precompile and install them. The Go community features wildly different repo and code structures, which means that go install <package> is likely to not work for a large number of packages, in light of this is that I've switched the default action to a less greedy gpm get, users that still want to run the extra install step can keep doing so via gpm install.

    The rest of the changes are small, mostly meta stuff like including contribution guidelines and the like. You can see the full commit changelog from v1.3.2 here.

    As always: love maintaining a feature-complete tool, it's a breeze, I highly recommend it.

    Happy 2016 everyone! :dancer: :tada: :balloon: :dancer:


    Source code(tar.gz)
    Source code(zip)
  • v1.3.2(Jan 30, 2015)

    Howdy dear gpm users!

    This minor release introduces the following changes

    Packages are prebuilt on gpm runs.

    This contribution by @juanibiapina ensures that all packages are prebuilt when gpm install runs, it follows the footsteps of @technosophos gpm-prebuild plugin and represents the first instance of core functionality that's imported from a plugin!

    Custom executable names on manual installs

    Turns out there is another package called gpm in linux: general purpose mouse server, as changing gpm's name would be highly bothersome @reinbach sent us a pull request which allows for a custom executable name on manual installations. Handy!

    Use STDERR for error messages

    This contribution by @foca makes sure errors on gpm install are piped to STDEER, because more POSIX is always a good thing. :)

    User /usr/bin/env sh rather than /bin/bash

    Speaking of POSIX, @prydie has been sending contributions to make gpm completely POSIX compatible, there is still more work by him to be merged, but this is certainly a good direction to head in.

    Check if $GOPATH is set before running.

    Another contribution by @juanibiapina , exiting early when $GOPATH is not set is definitely more intuitive and informative than waiting for go get to fail.


    I love the fact that gpm is feature-complete, makes maintaining it a breeze and allows for wonderfully specific contributions that focus on actual improvements instead of changing the nature of the tool, I'm super grateful for all the pull requests, issues and forms of contribution! :dancer:

    Happy Friday everyone!!!! :tada: :balloon:

    Source code(tar.gz)
    Source code(zip)
  • v1.3.1(Sep 28, 2014)

    This release marks the changes introduced in v1.3.0 as stable! It's been tested for some time and there are no bugs in sight as of yet, means we get goodies in stable gpm!

    You can update gpm via the manual install or in OSX by running:

    $ brew update && brew upgrade gpm
    Source code(tar.gz)
    Source code(zip)
  • v1.3.0(Sep 19, 2014)

    Releasing new gpm stuff has become one of my favourite friday activities! Without further ado here are the changes introduced in this release:

    Resolve install path based on :host/:user/:pkg - by @elcuervo .

    This makes it possible to have subpackages like in your Godeps file.

    Allow deps to be read from a file descriptor instead of a file - by @elcuervo

    This one-character change allows you to install a versioned dependency through gpm without a Godeps file through the magic of Unix. Here's how to use it:

    $ gpm install <(echo ' v6.1')

    Explicit error messages on unknown commands

    Unknown commands - that are not delegated to a gpm plugin - caused gpm to print the usage info and exit with a status code of 1, we thought adding a more explicit error would be nice.

    Refactor #set_dependencies function

    There have been a number of bugs we've had to tackle because of our choice to install packages and set their versions in parallel, this refactor tidies up the code in gpm's main function to separate package install and version locking so as to not be in each other's way - while still happening in parallel.

    Extensible Godeps format convention

    I've documented a convention that helps adding arbitrary data in any format to the Godeps file, this convention provides a nice way to add config data to any gpm plugin that cares to leverage it, I'm exited to see this put to good use. :)

    That's all for this release! I'll mark it as a pre-release because of the set_dependencies method refactor - I want to ensure that this won't have unexpected side effects on users so I'll wait for a few days before releasing this to homebrew, in the meantime you can install gpm manually if you want to take it for a spin!

    take it for a spin

    Source code(tar.gz)
    Source code(zip)
  • v1.2.3(Jun 17, 2014)

    Hello gophers!

    I'm happy to announce version v1.2.3 of gpm (better known as the One, Two, Three, Caramba! release) makes official the changes introduced in the v1.2.2 pre-release, namely: a more robust parallel installation approach. The user who had encountered the problem multiple times reports he hasn't had a problem since the patch, so we're now making it official. :)

    In principle this is intended to be a long term release: gpm is by and large a feature complete tool and one of the principles at its core has always been to keep it as simple and lean as possible. I do not expect any major updates in the future, which is a good thing.

    For those of you who might not be familiar with the release title reference: take a moment to enjoy this music video, which is so impossibly 80'ies that you won't be able to help yourself from bursting into a spontaneous spandex-friendly dance off.

    Have a happy week everybody!

    one, two, three, caramba!

    UPDATE: Homebrew users: gpm v1.2.3 is already updated in homebrew! Run brew update && brew install gpm to get the latest goodies. :dancer:

    Source code(tar.gz)
    Source code(zip)
  • v1.2.2(Jun 5, 2014)

    As discussed in issue #35 there is a potential problem on gpm install where some dependency of the packages we install through go get , this happens because gpm installs all packages in parallel for performance reasons.

    This version will be marked as a pre-release, we are attempting to solve this problem without having to cut out parallel package installation from the codebase, as that makes gpm quite a bit slower. My plan is to wait for one or two weeks and determine if this patch is the way to go or if we should sacrifice performance to make the tool more robust.

    If you have any thoughts or comments about this problem or fix please add them to the issue!.

    Keep on goph'in!

    adventure time!

    Source code(tar.gz)
    Source code(zip)
  • v1.2.1(Apr 11, 2014)

    There was an issue with plugin command delegation where the usage text was displayed on exit even after a successful execution, this is solved in v1.2.1 thanks to a PR by @adzankich.

    Happy Friday everyone!! :fireworks: :package: :fireworks:


    Source code(tar.gz)
    Source code(zip)
  • v1.2.0(Mar 25, 2014)

    The v1.2.0 release brings out some goodies brought to you by our expanding list of contributors!

    I thank everyone who has helped out by sending Pull Requests or cleaning up old issues, you've been outstanding. <3

    Godeps file parameter - by @chrsm

    This feature was included in some pre 1.0 versions of gpm but was dropped, dropping it was a bad idea though - I've recently come across some situations where it would fit perfectly, namely: dividing production dependencies and development dependencies.

    You wouldn't want your production env to have to import packages that won't be used in production, so it makes perfect sense to keep two Godeps files with separate dependencies.

    # File: Godeps   05aea7aa37c005073e309783aeabf5dbd0fad885
    # File:    37614ac27794505bf7867ca93aac883cadb6a5f7

    This means you can run gpm install && gpm install on your machine and will have all required dependencies but your build server is free to just run gpm install, tidier and will save you some build time. :)

    More POSIX! - by @badboy

    This won't change much of the user's interaction with gpm but it was a nice bit of trivia that I'm now applying to a lot of my code: the usage of which is actually discouraged in favour of command -v (you can read more about the reasons for that in the pull request


    SVN support! - by @chrsm

    Silly me, due to lack of caffeine I forgot to mention that svn hosted packages are now supported by gpm bringing the list of supported vcs to: git, bazaar, mercurial and subversion, or to put it differently gpm now supports every vcs supported by go get, which is fantastic news. :)

    That will be all for this release gophers! Happy versioning! :fireworks: :package: :fireworks:

    Source code(tar.gz)
    Source code(zip)
  • v1.1.1(Mar 8, 2014)

    TL;DR: gpm has plugins now, plugins are cool. :)

    As can be seen in my ramblings on this pull request there always are certain features which I want to add to gpm but which are not a good tradeoff in regards to functionality/complexity, or do not strictly fall into gpm's responsibility.

    That will stop being a problem from now on by introducing gpm plugins, their way they work is pretty simple: if you give an unknown command to gpm it will look for an executable called gpm-<command> in your path and execute that if present, passing along all arguments. The change was suggested by @foca, @inkel and @soveran to whom I extend my thanks ^_^.

    The first released plugin is gpm-bootstrap which takes a look at your Go project, installs all required dependencies setting them to their last release or revision and saves the versions to a Godeps file. Versioning the dependencies of your Go projects has never been easier.

    You can read more about plugins in the documentation.

    For homebrew users:

    I will keep up-to-date homebrew formulae for all plugins I'm aware of in this repository.

    You can access this formulae with the following command:

    $ brew tap pote/gpm_plugins

    After this you can just install them as you would any other package

    $ brew install gpm-bootstrap

    Plugin Example: gpm bootstrap


    Looking forward to seeing new plugins pop up! :package: :fireworks:

    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Mar 7, 2014)

    TL;DR: gpm has plugins now, plugins are cool. :)

    As can be seen in my ramblings on this pull request there always are certain features which I want to add to gpm but which are not a good tradeoff in regards to functionality/complexity, or do not strictly fall into gpm's responsibility.

    That will stop being a problem from now on by introducing gpm plugins, their way they work is pretty simple: if you give an unknown command to gpm it will look for an executable called gpm-<command> in your path and execute that if present, passing along all arguments. The change is introduced in this commit (it's a one liner, I love it) and was suggested by @foca, @inkel and @soveran, to whom I extend my thanks ^_^.

    The first released plugin is gpm-bootstrap which takes a look at your Go project, installs all required dependencies setting them to their last release or revision and saves the versions to a Godeps file. Versioning the dependencies of your Go projects has never been easier.

    You can see the plugin at work in this example:


    Looking forward to seeing new plugins pop up! :package: :fireworks:

    Source code(tar.gz)
    Source code(zip)
  • homebrew(Feb 14, 2014)

    As of today, the homebrew includes a gpm formula, meaning that users can install gpm in a single command, namely:

    $ brew install gpm

    I'm super happy about it, most of the praise should be directed at @elcuervo who championed the pull request though homebrew's process, if you see him at a conference or anywhere please give him a well-deserved hug, or buy him a beer, he'd like that. :)

    In related news: homebrew had a bit of a bad rep with the Go community as the installation formula was not really up to par, I had problems myself installing it this way a few months ago and was forced to install from source.

    I'm happy to report that at least now Go seems to work perfectly when installed from homebrew, I'm currently running 1.2 and the installation was a breeze. This should definitely be cause for celebration!

    :fireworks: :fireworks: brew install go :fireworks: :fireworks:

    Source code(tar.gz)
    Source code(zip)
  • v1.0.1(Feb 13, 2014)

    This minor update includes the following changes:

    • Appropriate error responses on missing go executable.

    gpm delegates fetching go packages to the appropriate directories to go get, while it's unusual for somebody using the tool to not have Go installed a gentler error message is never a bad thing

    • Lockfile usage for concurrent Mercurial and Bazaar hosted package installations.

    gpm installs all packages in parallel, a pull request by @elcuervo makes sure that an - admittedly rare - race condition is avoided.

    Happy gophing! :package:

    Source code(tar.gz)
    Source code(zip)
  • v1.0.0(Feb 4, 2014)

    This is it! gpm is has finally reached its 1.0.0 version and I honestly couldn't be happier.

    I spent a little bit of time over the weekend cleaning it up but I'm still surprised of how close the project is to the 7 lines of bash code that composed it initially. Sure, it's been polished and some features have come and gone but at it's core gpm is still deliciously minimalistic, it accomplishes it's goal in a straightforward way and without any clutter, the codebase is still minimal and easily readable and I've learned quite a few things about bash scripting along the way.

    What's in it for the future of gpm? Well, the requirements for go package management are not likely to change, we are currently working on getting gpm to a state where it can be more easily installed/updated across platforms, @elcuervo has been working to get it in homebrew for OS X users and maybe something similar for other platforms could be on the horizon.

    As far as future goes I've also released Go Versioning Packager (or gvp for short) which is a separate companion tool for gpm, in short it adapts your environment variables (GOPATH, GOBIN and PATH) to point to a local directory so you can keep the dependencies of your project isolated, it plays well with gpm, I'll probably be tinkering with it in the near future.

    I'm really grateful to everyone who has contributed comments, code, upvotes, issue requests, reddit comments or just plain used it, I'm really grateful for the opportunity to solve this problem for other people, it feels great, so once again: thank you everyone!

    clap_clap_win highest_of_fives i_regret_nothing im_awesome_ace_ventura joffrey_approves ninja_turtles_power_rangers no_one_should_criticize_me

    Contributed by @elcuervo: gpm_1_0

    Source code(tar.gz)
    Source code(zip)
  • v0.5.0(Feb 2, 2014)

  • v0.4.1(Oct 23, 2013)

    Users want to be able to install and update gpm using Homebrew, for which it's essential to have a command that outputs the version number of the library.

    @elcuervo has been driving the effort, which in turn forces me to think of cleaner CLI options for gpm, win/win for everyone, we'll update when we have news from the homebrew crew. :)

    Source code(tar.gz)
    Source code(zip)
  • v0.4.0(Oct 5, 2013)

    We've added support for Mercurial and Bazaar repos! This feature had been requested by several users so I'm happy to finally deliver on it.

    ▸ cat Godeps
    # Bazaar Repos                     r2013.03.03
    # Mercurial Repos    ae081cd1d6cc
    # Git Repos               v0.0.2
    ▸ gpm
    >> Getting package
    >> Getting package
    >> Getting package
    >> Setting to version v0.0.2
    >> Setting to version ae081cd1d6cc
    >> Setting to version r2013.03.03
    >> All Done

    Thanks to my partner-in-crime @elcuervo for suggesting a much more elegant approach than my initial implementation, he's the bomb.

    Source code(tar.gz)
    Source code(zip)
  • v0.3.1(Sep 9, 2013)

    It's usage is not recommended unless the project doesn't use tags for versioning.

    ▸ gpm -a -H
    >> Determining HEAD for
    >> HEAD for is  51b7af73e39f6dc59846b22d56ca886d105ef0c3
    >> Added to Godeps

    Closer to 1.0 :)

    Source code(tar.gz)
    Source code(zip)
  • v0.3.0(Sep 10, 2013)

    Now you can call gpm -a and it will automatically look up the latest release for the package and add it to your Godeps file. Pretty handy. :)

    $ gpm -a
    >> Determining last release for
    >> Last release for is v0.0.2
    >> Added to Godeps
    Source code(tar.gz)
    Source code(zip)
Acta non verba.
A simple dependency manager for Go (golang), inspired by Bundler.

Goop A dependency manager for Go (golang), inspired by Bundler. It is different from other dependency managers in that it does not force you to mess w

Peter Jihoon Kim 778 Sep 21, 2022
Go Package Manager (gopm) is a package manager and build tool for Go.

?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? In favor of Go Modules Proxy since Go 1.11, this pr

Go Package Manager 2.5k Sep 6, 2022
Go dependency management tool experiment (deprecated)

Dep dep is a dependency management tool for Go. It requires Go 1.9 or newer to compile. NOTE: Dep was an official experiment to implement a package ma

Go 13k Sep 18, 2022
dependency tool for go

Godep - Archived Please use dep or another tool instead. The rest of this readme is preserved for those that may still need its contents. godep helps

null 5.6k Sep 21, 2022
Spaghetti: a dependency analysis tool for Go packages

Spaghetti is an interactive web-based tool to help you understand the dependencies of a Go program, and to explore and evaluate various possible efforts to eliminate dependencies.

Alan Donovan 731 Sep 8, 2022
Go Dependency Analysis toolkit

Goda is a Go dependency analysis toolkit. It contains tools to figure out what your program is using.

Loov 852 Sep 22, 2022
Go Manager - bundle for go

gom - Go Manager Why The go get command is useful. But we want to fix the problem where package versions are different from the latest update. Are you

mattn 1.4k Sep 4, 2022
Golang Version Manager

g 注意:master分支可能处于开发之中并非稳定版本,请通过tag下载稳定版本的源代码,或通过release下载已编译的二进制可执行文件。 g是一个Linux、macOS、Windows下的命令行工具,可以提供一个便捷的多版本go环境的管理和切换。 特性 支持列出可供安装的go版本号 支持列出已安

voidint 790 Sep 25, 2022
🦄 Easy, fast and open-source local package manager for Python!

Unikorn ?? Easy, fast and open-source local package manager for Python! Key Features Speed: You can add a package in one second.

Penguen 6 Dec 11, 2021
gPac - a linux package manager

gPac is a useless package manager. It is included in the gSuite, which is a suite of tools written in GO. gPac is a KISS - like package manager.

Luis 4 Mar 13, 2022
GoFish is a cross-platform systems package manager, bringing the ease of use of Homebrew to Linux and Windows.

GoFish is a cross-platform systems package manager, bringing the ease of use of Homebrew to Linux and Windows.

Fishworks 815 Sep 20, 2022
Package manager for future projects

PCKGER is a package manager for my next project but when it will be able to build binaries and move libs it will be used like a normal package manager

null 0 Dec 20, 2021
gobin is a package manager for /go/bin

gobin gobin is a package manager for /go/bin Features List installed packages. Check for updates. Install packages (like go install). Uninstall packag

Andrey Burov 18 Feb 19, 2022
📦 An independent package manager for compiled binaries.

stew An independent package manager for compiled binaries. Features Easily distribute binaries across teams and private repositories. Get the latest r

Marwan Hawari 104 Sep 13, 2022
Barebones dependency manager for Go.

Johnny Deps Johnny Deps is a small tool from VividCortex that provides minimalistic dependency versioning for Go repositories using Git. Its primary p

VividCortex 213 Sep 2, 2022
Barebones Go program to issue DDNS updates to Amazon Route 53 service.

Route53 DDNS Very simple DDNS using AWS Route 53 #/bin/bash # AWS_ACCESS_KEY_ID example (fake) export AWS_ACCESS_KEY_ID=KkRbWpoyqLHo69dvoskn # AWS_

Chris Passas 12 May 17, 2021
A barebones URL Shortener implementation in Go using Gin and MySQL. Also features a basic frontend.

URL Shortener in Go This is a barebones URL Shortener implementation in Go using the Gin web framework and MySQL. Also features a basic frontend. Loca

Shreyas Gupta 6 Dec 22, 2021
🏥 Barebones, detailed health check library for Go

go-health ?? Barebones, detailed health check library for Go go-health does away with the kitchen sink mentality of other health check libraries. You

Jared Petersen 1 Oct 19, 2021
A barebones Go app, which can easily be deployed to Heroku

go-getting-started A barebones Go app, which can easily be deployed to Heroku. This application supports the Getting Started with Go on Heroku article

Chamod Jayampathi 0 Nov 29, 2021
A simple dependency manager for Go (golang), inspired by Bundler.

Goop A dependency manager for Go (golang), inspired by Bundler. It is different from other dependency managers in that it does not force you to mess w

Peter Jihoon Kim 778 Sep 21, 2022