6 ms·

What is the NPM equivalent in the Go world? I wanna give Go a start but can't see any community website that lists Go libraries like NPM. EDIT: I'm not asking

• melvinmt 13y ago
  go get/install <package-url>? http://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies http://golang.org/cmd/go/#hdr-Download_and_install_packages_...
  • oakaz 13y ago
    It's the equivalent of npm install <package-url> command, not the NPM.
    • _ak 13y ago
      Why would you need a central repository when you can have a completely decentralized repo system?
      • snaky 13y ago
        Why do you see a contradiction? CPAN is a central repository while vast majority of packages development now is backed by GitHub, for example.
• mvzink 13y ago
  $ go get github.com/person/project It will even figure out dependencies by checking every import (and you can do 'import "github.com/person/project"' too), and builds the source by default. And yes, "go get" comes with the standard gotools.
  • oakaz 13y ago
    As I said in my previous comment, it's just the equivalent of `npm install person/project` not NPM. Edit: WTF? why this comment is down-voted now?
    • rubinelli 13y ago
      Ah! You mean CPAN! Nothing that I'm aware yet. It's mostly community-based discovery and recommendations, but a centralized repository would sure be nice.
    • shurcooL 13y ago
      I'm not sure if there's a direct equivalent, but see if any of these are helpful. http://godoc.org/ http://godoc.org/ http://go-lang.cat-v.org/ http://go-lang.cat-v.org/ https://code.google.com/p/go-wiki/wiki/Projects https://code.google.com/p/go-wiki/wiki/Projects
• exch 13y ago
  To get a good overview of third party libraries 'out there', you can browse the index at http://godoc.org/-/index http://godoc.org/-/index 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/ http://goci.me/
  • oakaz 13y ago
    No offense but that page is horrible. I liked the project pages though. I think Go needs to focus on improving its community and its aesthetic culture.
    • frou_dh 13y ago
      > 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.
    • voidlogic 13y ago
      >>improving its community 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...
    • jussij 13y ago
      > No offense but that page is horrible. 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!
• mmgutz 13y ago
  `go get` but it's not anywhere as featured as npm. Forget about versions or using yours or anybody else's fork of a project without editing code or using symlinks. "github.com/your_fork/somelib" is not a replacement for "github.com/foo/somelib". For those that don't use node, using a fork or a specific commit in node is a simple version change in package.json.
  • oakaz 13y ago
    who is talking about forks or versions here? try this in your command-line: npm install name/project
    • mmgutz 13y ago
      npm does a lot more than that npm install pkg@1.2.3 npm install foo/bar#cfdea4213
• encoderer 13y ago
  I see what you're saying in your replies down-thread from this, but honestly the fact that there's not a directory of packages has never been an issue for me. I google when I go looking for a package, then "go get" it.
  • oakaz 13y ago
    Is this the most productive way of coding?
    • encoderer 13y ago
      Honestly I've spent more time installing NPM than I have searching for packages when I need them. Which is not very much time.
      • snaky 13y ago
        And when you can't find the packages you write them. And at the end of day that's so nice to have a bunch of packages for each not-so-popular task, yeah.
        • encoderer 13y ago
          You think NPM solves discovery? 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.
          • snaky 13y ago
            >You think NPM solves discovery? I know CPAN does.
• burntsushi 13y ago
  > As I observe, Go projects are really messy. I saw some code importing code like "import github.com/foo/bar". 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 https://code.google.com/p/go-wiki/wiki/Projects [2] - http://godoc.org/-/index http://godoc.org/-/index
  • oakaz 13y ago
    > That's not messy; that's idiomatic Go 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. > http://godoc.org/-/index http://godoc.org/-/index This link is actually a self-answer by you.
    • drivebyacct2 13y ago
      You clearly haven't a single clue what you're talking about. I've never, ever, ever heard someone describe Go this way: >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.
      • oakaz 13y ago
• drivebyacct2 13y ago
  What on Earth are you talking about? Go's dependency system tied to SCM is awesome.
  • teraflop 13y ago
    It has a crucial limitation compared to "real" dependency managers like Ivy, Maven, NPM, Leiningen, pip, et al.: you can't declare a dependency on a particular version of a module, only on the trunk. So you have to either maintain local mirrors of every single module, or just give up on reproducible builds and accept that upstream might introduce a bug or a breaking change at any time. 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/discussion https://groups.google.com/d/topic/golang-nuts/3gEseiCwdf0/di...
    • burntsushi 13y ago
      It's because it isn't a trivial problem to solve. What happens when A requires B1 and C, but C requires B2? > 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.
      • teraflop 13y ago
        Certainly there will be cases where there are conflicts between different versions of packages, but Go's current behavior doesn't prevent them; it just makes them happen unpredictably. Instead of building against a specific known version, you're just using whichever one happened to be the most recent as of the first time you referenced it. 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.)