By default, Goop use go get -u [REPO], however go get -u cant fetch private dependencies.

The workaround right now is to use .netrc file to specify credentials for the remote repository (i.e. github), but it would be nice to be able to specify a git src and use it.

Features from this pull request

By leverage the npm command, I added the package installation support to goop install, then you can use:

• goop install to continue installing all packages from the local Goopfile file
• goop install github.com/revel/revel to install one package you specified from the command line
• goop install github.com/revel/revel #tag to install the package with the specified tag name

And also, there is one new arg supported to the install command, which is --save-dev which is the same as npm,

• goop install github.com/revel/revel --save-dev, the goop command will install the package github.com/revel/revel and it will also append the package github.com/revel/revel to the Goopfile file for convenient, or
• goop install --save-dev github.com/revel/revel which is the same as goop install github.com/revel/revel --save-dev

Changes are made

Added the install arg support to the main.go file;

Added one new method InstallPkg to goop/goop.go file, logic:

• Create one tmp file ".Goopfile" and copy all the packages from "Goopfile" if it exists to ".Goopfile"
• Append the new package to the end of this file
• Call g.parseAndInstall(gftmp, true) to reuse the original logic to install the new packages in the file ".Goopfile"
• If --save-dev is true, then mv the tmp file ".Goopfile" to "Goopfile"

I might be mistaken, but it seems that goop creates a lock file for the top level dependencies only. For example, if I list module 'A' as a dependency and it has module 'B' as a dependency, my lock file will contain a revision hash for module A but nothing about module B.

Is that correct? If so, how can we make sure that changes to module B would not affect our locked versions in future?

Python developer here. You wouldn't believe how useful it is to allow comments on dependencies declarations, we do that all the time in the python world (in our requirements.txt files, used to install dependencies with the pip python tool). Things like "don't update to newer versions, this is the last compatible one", or "we are using this for feature/module x", etc.

I've been able to use goop with a trivial main.go example, but I've been unable to figure out how to use goop with a folder structure containing a package main and one or more other packages.

My folder structure looks like below:

Goopfile
src/myproj
   - main.go
   - client/client.go

I'm using goop go build src/myproj/main.go to build package main, but for the life of me I can't figure out how to build/import the client package. I would really appreciate an example that works.

if I add one dep in Goopfile, such as

github.com/gohttp/app #5fe28eda25acc96b48d8f2ddb651ea9104cc3e7c

I want to do goop install --auto-parse

and the deps of github.com/gohttp/app will be parsed, and saved to Goopfile

so, the result will be:

github.com/gohttp/app #5fe28eda25acc96b48d8f2ddb651ea9104cc3e7c
github.com/justinas/alice #e82c7d9ec9ebfd83e90d4fd39ce934f5fc0b0b5f
github.com/bmizerany/pat #b8a35001b773c267eb260a691f4e5499a3531600

Go version: 1.3 OS: OS X

Goopfile

github.com/zenazn/goji

Error message:

=> Installing github.com/zenazn/goji...
WORK=/var/folders/cg/gtgtb84d4cx135ml8wtpc88r0000gn/T/go-build596648851
mkdir -p $WORK/github.com/zenazn/goji/bind/_obj/
mkdir -p $WORK/github.com/zenazn/goji/
cd /private/tmp/test/.vendor/src/github.com/zenazn/goji/bind
/usr/local/Cellar/go/1.3/libexec/pkg/tool/darwin_amd64/6g -o $WORK/github.com/zenazn/goji/bind.a -trimpath $WORK -p github.com/zenazn/goji/bind -complete -D _/private/tmp/test/.vendor/src/github.com/zenazn/goji/bind -I $WORK -pack ./bind.go ./einhorn.go ./systemd.go
mkdir -p $WORK/github.com/zenazn/goji/graceful/_obj/
cd /private/tmp/test/.vendor/src/github.com/zenazn/goji/graceful
/usr/local/Cellar/go/1.3/libexec/pkg/tool/darwin_amd64/6g -o $WORK/github.com/zenazn/goji/graceful.a -trimpath $WORK -p github.com/zenazn/goji/graceful -complete -D _/private/tmp/test/.vendor/src/github.com/zenazn/goji/graceful -I $WORK -pack ./einhorn.go ./graceful.go ./middleware.go ./net.go ./signal.go
mkdir -p $WORK/github.com/zenazn/goji/web/_obj/
cd /private/tmp/test/.vendor/src/github.com/zenazn/goji/web
/usr/local/Cellar/go/1.3/libexec/pkg/tool/darwin_amd64/6g -o $WORK/github.com/zenazn/goji/web.a -trimpath $WORK -p github.com/zenazn/goji/web -complete -D _/private/tmp/test/.vendor/src/github.com/zenazn/goji/web -I $WORK -pack ./atomic.go ./fast_router.go ./func_equal.go ./middleware.go ./mux.go ./pattern.go ./router.go ./web.go
mkdir -p /private/tmp/test/.vendor/pkg/darwin_amd64/github.com/zenazn/goji/
mv $WORK/github.com/zenazn/goji/bind.a /private/tmp/test/.vendor/pkg/darwin_amd64/github.com/zenazn/goji/bind.a
mv $WORK/github.com/zenazn/goji/graceful.a /private/tmp/test/.vendor/pkg/darwin_amd64/github.com/zenazn/goji/graceful.a
mv $WORK/github.com/zenazn/goji/web.a /private/tmp/test/.vendor/pkg/darwin_amd64/github.com/zenazn/goji/web.a
mkdir -p $WORK/github.com/zenazn/goji/web/middleware/_obj/
mkdir -p $WORK/github.com/zenazn/goji/web/
cd /private/tmp/test/.vendor/src/github.com/zenazn/goji/web/middleware
/usr/local/Cellar/go/1.3/libexec/pkg/tool/darwin_amd64/6g -o $WORK/github.com/zenazn/goji/web/middleware.a -trimpath $WORK -p github.com/zenazn/goji/web/middleware -complete -D _/private/tmp/test/.vendor/src/github.com/zenazn/goji/web/middleware -I $WORK -I /private/tmp/test/.vendor/pkg/darwin_amd64 -pack ./envinit.go ./logger.go ./middleware.go ./nocache.go ./options.go ./realip.go ./recoverer.go ./request_id.go ./terminal.go ./writer_proxy.go
mkdir -p /private/tmp/test/.vendor/pkg/darwin_amd64/github.com/zenazn/goji/web/
mv $WORK/github.com/zenazn/goji/web/middleware.a /private/tmp/test/.vendor/pkg/darwin_amd64/github.com/zenazn/goji/web/middleware.a
mkdir -p $WORK/github.com/zenazn/goji/_obj/
mkdir -p $WORK/github.com/zenazn/
cd /private/tmp/test/.vendor/src/github.com/zenazn/goji
/usr/local/Cellar/go/1.3/libexec/pkg/tool/darwin_amd64/6g -o $WORK/github.com/zenazn/goji.a -trimpath $WORK -p github.com/zenazn/goji -complete -D _/private/tmp/test/.vendor/src/github.com/zenazn/goji -I $WORK -I /private/tmp/test/.vendor/pkg/darwin_amd64 -pack ./default.go ./goji.go
mkdir -p /private/tmp/test/.vendor/pkg/darwin_amd64/github.com/zenazn/
mv $WORK/github.com/zenazn/goji.a /private/tmp/test/.vendor/pkg/darwin_amd64/github.com/zenazn/goji.a
goop: readdirent: invalid argument

I thought that the main function in main.go could use a little refactoring. I'm new to Go, coming from Ruby, so this might not be the kind of thing done in this language, but I thought this might make the code a little more maintainable and expressive.

A separate moving branch (I.E. "develop", for git-flow style workflows) can given as a reference. Revision-locking for repeatable builds makes just as much sense, regardless of branch.

go get github.com/nitrous-io/goop
package code.google.com/p/go.tools/go/vcs: Get https://code.google.com/p/go/source/checkout?repo=tools: x509: failed to load system roots and no roots provided

Where did I go wrong?

This fixes #4 (set GOBIN) and #8 (replace GOPATH), and adds a "deactivate" command similar to the same command in virtualenv.

You may or may not be interested in these changes, but I thought I'd throw them out there. A couple of thoughts:

• deactivate is definitely useful, but only works for Bourne shell variants (sh, bash, zsh). Won't work for csh, fish, etc. It would be a bit more work to make it work across shells.
• I'm not sure what your opinion on #4 and #8 are, so you might not want those changes. I can back them out.

eg.

Activate an environment:

~/Projects/3rdParty/goop$ goop env
_OLD_GOPATH="$GOPATH"
_OLD_GOBIN="$GOBIN"
_OLD_PATH="$PATH"
GOPATH=/Users/alec/Projects/3rdParty/goop/.vendor
GOBIN=/Users/alec/Projects/3rdParty/goop/.vendor/bin
PATH=/Users/alec/Projects/3rdParty/goop/.vendor/bin:/usr/local/bin:/usr/local/go/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/alec/.cabal/bin

Deactivate an environment:

~/Projects/3rdParty/goop$ goop deactivate
GOPATH="$_OLD_GOPATH"
unset _OLD_GOPATH
GOBIN="$_OLD_GOBIN"
unset _OLD_GOBIN
PATH="$_OLD_PATH"
unset _OLD_PATH

warning: code.google.com is shutting down; import path code.google.com/p/go.tools/go/vcs will stop working

receiving this error during goop install. is this library available through any other sources? thanks!

goop is so GREAT and I love it! Used it alot since I found it, thanks a lot for the tool.

But I have a minor problem recurring in my development process, in the process I often need to add new dependencies to the project, but I have problems installing ONLY the new dependencies without touching others. The first thing I tried was adding an entry in the Goopfile then goop install, but goop install just ignore the changed Goopfile and picked-up the content of Goopfile.lock. Then I tried goop update, it do install the new dependencies, but as the help text indicates it also update all dependencies to latest version, I'd rather not to do it this way as it may compromise the stability of my project. Then I tried adding entries directly in Goopfile.lock then goop install, but this does not add entries of 'dependencies of dependencies' to the Goopfile.lock, thus leaving unlocked versions flying around.

So what should I do in this situation? I think my use case is a very general one, so maybe there is already a way to do it and I missed it.

In 1.5 the go command will read the environment variable GO15VENDOREXPERIMENT. If enabled, it will use the local "/vendor/" folder for dependencies.

Will you consider supporting this approach?

Hi there,

I think I may have found a bug with how Goopfile works. It seems that if you have multiple dependencies located in the same GitHub repo, the individual dependencies must be listed in the order oldest to newest or else they do not get updated properly.

For example, for my project called MumbleDJ, I need to fetch five dependencies: gumble, gumble_ffmpeg, gumbleutil, gcfg, and jsonq. If I put the dependencies in my Goopfile in this order, it does not completely update all of the dependencies (the commit specified for gumble is newer than the commit for gumble_ffmpeg, and gumble_ffmpeg is newer than gumbleutil):

github.com/layeh/gumble/gumble #80248757d681a7563d7257ff645ea27250f9d42d
github.com/layeh/gumble/gumble_ffmpeg #7ca5605a1e735c95442683ef47be117b0b9cb042
github.com/layeh/gumble/gumbleutil #29411f8e62add7e8f0856b35dc925cf879be3aab
code.google.com/p/gcfg #c2d3050044d0
github.com/jmoiron/jsonq #7c27c8eb9f6831555a4209f6a7d579159e766a3c

However, if I put them in this order, the updates are fetched correctly:

github.com/layeh/gumble/gumbleutil #29411f8e62add7e8f0856b35dc925cf879be3aab
github.com/layeh/gumble/gumble_ffmpeg #7ca5605a1e735c95442683ef47be117b0b9cb042
github.com/layeh/gumble/gumble #80248757d681a7563d7257ff645ea27250f9d42d
code.google.com/p/gcfg #c2d3050044d0
github.com/jmoiron/jsonq #7c27c8eb9f6831555a4209f6a7d579159e766a3c

The same dependencies and SHA hashes produce different results when put in different orders. Maybe I've missed something about how goop works, but it doesn't seem to make sense to me that the order of the dependencies in Goopfile should matter.

Thanks!