Releases: pote/gpm
`gpm get` is now the default action.
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! 💃 🎉 🎈 💃
Prebuild ALL the things.
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.
Summary
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! 💃
Happy Friday everyone!!!! 🎉 🎈
v1.3.1 Stable
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 gpmRobustness, extensibility conventions and Unix tricks!
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 github.com/garyburd/redigo/redis 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 'github.com/pote/gpm-testing-package 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!
One, two, three, Caramba!
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!
UPDATE: Homebrew users: gpm v1.2.3 is already updated in homebrew! Run brew update && brew install gpm to get the latest goodies. 💃
More robust race condition prevention.
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!
[Minor] Plugin output improvement
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!! 🎆 📦 🎆
Goodies by contributors!
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
github.com/codegangsta/martini 05aea7aa37c005073e309783aeabf5dbd0fad885
--
# File: Godeps.dev
github.com/stretchr/testify 37614ac27794505bf7867ca93aac883cadb6a5f7
This means you can run gpm install && gpm install Godeps.dev 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
UPDATE
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! 🎆 📦 🎆
Introducing: Plugins
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_pluginsAfter this you can just install them as you would any other package
$ brew install gpm-bootstrapPlugin Example: gpm bootstrap
Looking forward to seeing new plugins pop up! 📦 🎆
Experimental Plugins
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! 📦 🎆