

Gigo: Pip for Go - cik
https://www.github.com/LyricalSecurity/gigo

======
cik
I love the ability to go get things... but from a multi-component perspective,
go-get doesn't really work with our environment, specifically the notion of
multiple deploy keys, private repositories or hyper-componentized go
codebases.

So, our awesome co-op wrote gigo. Over time, we'll extend it (or hey, pull
request!) it to do other, better things. But for now, it makes fetching
private repositories a breeze, in the laziest/happiest way we could possibly
think of.

Hope someone else finds this useful.

~~~
cik
I'm going to reply to myself, since a friend asked about vendoring.

Our current flow is just to privately (and occasionally publicly) fork
something that we care about - to solve the vendoring issue. I could easily
see vendoring original sources for builds within gigo, that way we use
something like bruise to make it easy to support a virtualenv-like thing for
golang.

But today, that's not the problem we had.

------
Queue29
add it to the list

[https://github.com/golang/go/wiki/PackageManagementTools](https://github.com/golang/go/wiki/PackageManagementTools)

~~~
ahmetmsft
You should probably add to [https://github.com/avelino/awesome-
go](https://github.com/avelino/awesome-go) as well

~~~
cik
Thanks - I did... and merged your pull request ;)

------
mickgardner
There is a huge number of go package management tools being developed at the
moment. It seems like there's a new one each day! I'm hoping the Golang
developers can pay attention to what's going on in the community and propose a
more official solution? I realise they recently proposed 'vendoring' but the
Golang community seems to have mostly ignored that suggestion.

------
jzelinskie
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](https://github.com/tools/godep)

------
kolev
Pip is bad advertising - it's probably the worse package manager compared to,
let's say, NPM.

~~~
Ysx
I wouldn't say pip's the worst, but NPM outshines it in my opinion.

Some useful features include:

* `npm --save $PACKAGE` - installs a package, adds it to your dependencies list. Python's equivalent is `pip install`, `pip freeze` to get the installed version, and a manual edit of the requirements file.

* Production dependencies & development dependencies. Python either has to use multiple files, or `setup.py`, which is vastly more complex.

* Installation of modules within the source directory - no need of a virtualenv. This isn't always good news, but it's generally pretty useful.

* Recursive dependencies. There's no global version of a module - your dependencies can in turn require different versions of other packages, without clobbering each other.

~~~
pyre
> Installation of modules within the source directory - no need of a
> virtualenv. This isn't always good news, but it's generally pretty useful.

This isn't really a feature of npm or a failing of pip. Isn't this more of an
evaluation of Node.js vs. Python? I'm sure that if Python loaded a local
python_modules directory by default, pip would use it.

