I wanna give Go a start but can't see any community website that lists Go libraries like NPM.
EDIT: I'm not asking for "npm install person/project", I'm asking for a community website and a file like package.json that records information about a project.
As I observe, Go projects are really messy. I saw some code importing dependencies like "import github.com/foo/bar".
I think Go should focus on declarative programming and its aesthetics culture.
That's not messy; that's idiomatic Go. By convention, package imports can be URLs to version control repositories, which the `go` tool uses to determine dependencies and install them automatically.
Go has no equivalent `package.json` file. All package information is inferred from the source code.
The closest thing to a central repository is on the Go wiki. [1] Many people also use godoc.org [2], which is searchable.
[1] - https://code.google.com/p/go-wiki/wiki/Projects
[2] - http://godoc.org/-/index
The two aren’t mutually exclusive. If that URL goes down, is there a fallback mechanism?
For what it’s worth, I agree with oakaz’s sentiment that Go is “very imperative” and “not simple”. It is deliberately designed that way, with lots of syntax and types for representing (abstractly) the inherent complexities of its intended domain. Any ugliness, however, is purely subjective.
The OP (of this thread) said, 'I saw some code importing dependencies like "import github.com/foo/bar."' I did not understand this as a criticism of the design choice of using URLs as imports, but rather, a statement about some Go projects doing something horrendously wrong.
Yes, one can think URLs as imports is both messy and idiomatic, but I do not feel that was central point of the OP. I suspect we will never get a clarification, though.
> If that URL goes down, is there a fallback mechanism?
I don't know what you mean. If the package is no longer available at the URL then it cannot be downloaded from that URL.
> For what it’s worth, I agree with oakaz’s sentiment that Go is “very imperative” and “not simple”. It is deliberately designed that way, with lots of syntax and types for representing (abstractly) the inherent complexities of its intended domain.
Go was not deliberately designed to be "not simple." In fact, it was deliberately designed to be simple. Simplicity's name is invoked again and again as a justification for including or not including changes to the language.
Haha.
Everybody understands Go has a tool that deals with dependencies for you. And any other language can have it.
And this is why I avoid monopolistic platforms even though they are fast. If the owner of your platform has no taste of aesthetics, you'll write fast and ugly looking code. which is not fun for me.
As PG says in his book, a good solution should also look good and simple.
Go is very imperative, ugly looking, and not simple.
This link is actually a self-answer by you.
I disagree.
>Go is very imperative and ugly looking, and not simple.
Further, this is just stupid:
>And this is why I avoid monopolistic platforms even though they are fast.
If you don't want to use `go`, so be it. The manual compiler and linker tools are available that you can cobble together with make or ant or whatever masochistic tool you prefer.
>This link is actually a self-answer by you.
What are you whining about? What do you want? That's just a laundry list of known/seen Go packages. As everyone else has already told you, there's no need for a package.json and this literally isn't a problem for anyone actually writing Go code.
These are by no means all the 3rd party stuff out there, but it's a good starting point.
Incidentally, this website is intended to automatically generate and serve the documentation for all those projects in a centralized place. You don't even have to submit your projects. Just type the import path in the search box, and the site fetches the code by itself.
Edit: And here's anther community-built site to do continuous integration testing for your projects. It too, has an index of registered projects: http://goci.me/
I think Go needs to focus on improving its community and its aesthetic culture.
You seem more eager to make grand proclamations than to gain understanding.
I'm pretty sure that page is auto generated by GoDoc, an automatic documentation tool that generates documentation on the fly.
For auto generated documentation I'd say it looks pretty darn good!
You must read different mailing lists, G+ groups and IRC channels than I do...
>>and its aesthetic culture.
ROFL, what? How do you feel about the "aesthetic culture" of C programmers? Because you know- thats not a very popular language or anything...
try this in your command-line: npm install name/project
npm install pkg@1.2.3
npm install foo/bar#cfdea4213
$ go get github.com/person/project
And yes, "go get" comes with the standard gotools.
Edit: WTF? why this comment is down-voted now?
Nothing that I'm aware yet. It's mostly community-based discovery and recommendations, but a centralized repository would sure be nice.
Look if you or Oakaz feel so strongly, go build that centralized repository. But looking at centralized repos in different languages there are as many misses as hits. And even among hits -- pip for example -- the core benefit pip provides IMO is not discovery. More often than not, I find a Python package via a Google search and then merely install it using pip.
Your snark here is a little absurd IMO.
I know CPAN does.
http://golang.org/cmd/go/#hdr-Download_and_install_packages_...
The Go developers are aware of this limitation, and their typical recommendation on the mailing list is that you should never need to use anything other than the latest version of any third-party library, e.g.: https://groups.google.com/d/topic/golang-nuts/3gEseiCwdf0/di...
> The Go developers are aware of this limitation, and their typical recommendation on the mailing list is that you should never need to use anything other than the latest version of any third-party library
It's either that, or you pin the version you want in your own fork of the package. Which is not an unreasonable solution to the bitrot problem.
Regardless, this limitation doesn't stop the `go` tool from being awesome. It's easily one of the reasons why I use Go in the first place.
If B1 and B2 are really incompatible, then yes, there's a problem; but not being able to solve the problem completely in all cases doesn't mean we need to throw our hands in the air and not even try to handle the simple cases. I think it's telling that Google uses a custom build system for their Go projects, rather than "go get".
(And forking all of your dependencies is an option, but it's not quite that simple. In order to get truly reproducible builds, you have to mirror all of their dependencies as well, and patch all of your forked versions to fix their imports.)
It's not just incompatibility at the package level. Allowing them to simply coexist in the `GOPATH` ecosystem is problematic. It isn't technically difficult to offer a package tool that can handle different but compatible versions of a library, but it certainly increases the complexity of the system. The simple directory structure of `GOPATH` and its correspondence with import URLs would be lost.
> In order to get truly reproducible builds
Yes, if that's what you need then you'll have to pay that price. But not everyone needs that. For software I release, I only pin dependencies when they have a track record of breaking or don't update frequently enough for my purposes. In practice, it's pretty rare.
> If B1 and B2 are really incompatible, then yes, there's a problem; but not being able to solve the problem completely in all cases doesn't mean we need to throw our hands in the air and not even try to handle the simple cases.
That's ironic because that's exactly how I see the `go` tool. Package management is extremely difficult to get right, so instead of throwing their hands in the air, the Go devs put out a tool that is simple to use and has proven to work very well in practice.
The fact that the `go` tool is so simple is one of the reasons why I love it so much. If and when I need to be 100% confident in my builds, I'll happily pay the price to make it so.
Google uses custom build systems for lots of things ;)
In fact, to not under-generalize, I think it's safe to remove 'build' from the previous sentence.
It's not only an option, it's a practical necessity to freeze the dependency tree locally so you can run a rebuild when someone's knocked the remote repository offline. Doesn't everyone do this?
Mind you ruby also has a central repository in the form of rubygems which allows for this kind of versioning.
Go, lacking the same thing, relies on people just entering github URLS which seems insane to me but could work I guess if everyone agrees to tag their projects using semantic versioning where appropriate. Then you could do something like person/project@v1.2.3
Mind you, of any of the companies on the planet I could think of that has the resources to to create, manage and maintain a rubygems equivalent for go, Google would be top of the list.
There's no need to guess. It works. Almost the entire Go ecosystem uses it.
> Then you could do something like person/project@v1.2.3
This has been suggested. But it's just a mechanism for versioned dependencies; it doesn't address the transitive dependency problem that I cited.
As of right now, if you need to pin a dependency to a particular version, then you fork it yourself. I welcome this infrequent pain with open arms to the benefit of keeping the `go` tool simple.
It's not like people haven't tried to setup a central repository with versioned packages [1], but it just hasn't caught on.
[1] - http://www.gonuts.io/
For a given definition of "works". Personally speaking, my "good" has not been met but of course, each to their own. The "Fork it if you want version x" workaround also would not satisfy me.
Google has the resources, reach and authority to easily setup a central repository. If they did then I would not be surprised to see people start using it like CPAN and rubygems.
You say you do not want the go tool to become complex but there is no reason the dependency management side of things cannot be done with a separate tool to keep things segregated.
The current tool seems to roughly match the ruby 'gem' command (albeit with-out a central repository). I am surprised google has not created an analogue of the ruby 'bundler' gem with its 'bundle' command.
Yes. I addressed that.
And if that package references another package on github understandably I need to pin it too, but do I also need to modify all of the imports in the original third party package I wanted to reference the pinned dependency?
Only if you want to. You don't have to.
> but do I also need to modify all of the imports in the original third party package I wanted to reference the pinned dependency?
Yes, but it's trivial:
find ./ -name '*.go' -print0 | xargs -0 \
sed -i 's#github.com/BurntSushi/wingo#github.com/YourName/wingo#g'I guess I don't understand why it's expected that I would run production code that imports from a third party automatically. I don't want to deploy updates some random person committed today to some third party package I'm using or some package it depends on, so if I want to use a third party package I have to recursively pin it and its dependencies and recursively modify import statements.
Along those lines, did you know that Maven2 (and possibly in Maven 3) it's possible to have dependencies that are pulled into your bundle that are at a lower version that specified in a top level pom? Yup, versioning is really hard.