gpm bootstrap command

[pote]

Pros

gpm bootstrap is intended to help users adopt gpm by creating a Godeps dependency file based on the Go code of a project, management of the Godeps file after this initial creation is up to the user but gpm ensures that they have a decent starting point, this makes it easier for beginners.

(This PR references issue #18)

Sample usage:

Hyrule ~/code/gpm/test   (git: gpm_bootstrap)
▸ cat go_code.go
package main

import (
    "fmt"
    "github.com/pote/gpm-testing-package"
)

func main() {
    fmt.Println(gpm_testing_package.Version())
}

Hyrule ~/code/gpm/test   (git: gpm_bootstrap)
▸ gpm bootstrap
>> Installing dependencies.
>> Adding package github.com/pote/gpm-testing-package version v6.2  to Godeps.
>> All Done.

Hyrule ~/code/gpm/test   (git: gpm_bootstrap)
▸ cat Godeps
github.com/pote/gpm-testing-package v6.2

Cons

This is a rather complex feature, and and imperfect one too. As a discussion starting point we can see that this PR takes bin/gpm from 78 LOC to 179, which speaks volumes: is the complexity inherent to this feature worth the readability/maintenance overhead for the project? I'm not sure, I would hope we can discuss that in this PR.

The second downside is that this feature is imperfect: it uses go list to get a list of packages imported in your Go project, but this listing is not straight forward to use: it includes subpackages too, you can see this in the following sample usage:

Hyrule ~/code/minimalweather  (git: master)
▸ go list -f '{{join .Deps "\n"}}' | xargs go list -f '{{if not .Standard}}{{.ImportPath}}{{end}}'
github.com/elcuervo/minimalweather/minimalweather
github.com/elcuervo/minimalweather/pages
github.com/elcuervo/minimalweather/routes

What rule should I use to determine which if these import paths I actually want in my Godeps file considering they are the same repository? I've "solved" this by having gpm bootstrap only consider top level packages (I.E: where the import path corresponds to a $GOPATH/src/<import_path> directory).

This is imperfect because it will ignore Go packages that don't have a top-level package, maybe a repository has a list of subpackages which you import but if the repo root itself is not a package then it will be ignored.

I think this should not be a big issue because in practice repositories that don't have a top-level package tend to be applications, not libraries, and so you're not likely to be importing those, but it does make this feature imperfect in gpm for some use cases without a doubt.

Summary

This feature provides a nicer user experience, but adds a non-trivial amount of complexity and is imperfect. Should it be added?

[pote]

There is a great idea proposed by folks at the #microrb IRC channel to add a lightweight plugin system for gpm, which would mean that bootstrap would simply be a separate repository and project but could be simply pluggable into gpm.

I like this idea a lot, will have to think on how to implement it, this also alleviates the problem of the added complexity to gpm.

[foca]

I totally agree with moving this out and having the case statement attempt to search for gpm-whatever whenever you call gpm whatever.

[pote]

Closing this PR in favour of the plugin approach, you can read all about it in the release notes :) 📦