Gigo: Pip for Go | Hacker News Reader

Gigo: Pip for Go

github.com

51 pointscik21 comments

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.

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.

add it to the list

https://github.com/golang/go/wiki/PackageManagementTools

You should probably add to https://github.com/avelino/awesome-go as well

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

Thanks Queue, will do.

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.

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

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

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.

> 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.

Why is it bad advertising? Pip works all the time for me, where NPM often doesn't work.

Why doesn't NPM work for you? If it's an user-permission thing (which is common if you installed node straight-up), consider installing nodejs using NVM (node version manager). This also has the advantage that you don't have to sudo npm.

I've had issues with NPM in the past due to having a proxy server on our network, and dealing with some absurdly arcane errors t oresolve it. The only package manager that I've ever had a problem with.

That said, I don't tend to use node.js, so NPM's virtues illude me.

I usually have to google two to three errors that popup on an npm install --save to get things working and sometimes I don't. Its quite inconsistent, but these issues are probably with node versioning as well. In any case I never have this issue with pip.

NPM is not a great package manager either. Specifically, there is no way to do the following:

- output your `node_modules` directory to anywhere other than the current directory. You can move it after the fact, but your package.json needs to be in CWD for npm to work. - move/don't use the `$HOME/.npm` directory - have deduplicated node dependencies in an app

What makes it bad? It just works.

"It just works" isn't an argument. Of course it works, but it doesn't work as nicely as NPM, RubyGems, and others.

Can you explain what doesn't work as nicely?

We all got used to the better tools and get their features of the box. I need to use a bunch of third-party tools with pip (which often break due to changes in the pip core) to have similar functionality available.

Ok.... But what are those features that you got used to and that pip lacks? I actually dont know here. Like specifics.

Reply on news.ycombinator.com