4 ms·

Looong overdue... With Go being a new language (1.0 in 2012), there is no excuse for not having had a solid pkg solution in 1.0. It's one of the things holdin

Looong overdue... With Go being a new language (1.0 in 2012), there is no excuse for not having had a solid pkg solution in 1.0. It's one of the things holding Go back, in my opinion, producing makeshift solutions like Glide and gopkg.in, which are only minimally adopted. I hope they also specify some mandatory versioning scheme (like npm with semver), because there are so many Go packages out there which don't even do any versioning!

zzzcpan 10y ago
But the solutions don't offer much over "go get", what would be the point to use them?
- the_duke 10y ago
  I thoroughly disagree. The Golang ecosystem is in an incredibly weak state when you compare it with other modern languages. Major issues: -) Due to the lack of a proper package system, there's also no central pkg repository, which really hurts discoverabilty and growth of the ecosystem a lot. Just compare it to solutions like NPM for node, https://crates.io https://crates.io for Rust, Hackage for Haskell, etc... Github + https://godoc.org/ https://godoc.org/ is not a replacement for a proper package repository. -) Like I mentioned, way, way too many Go packages don't follow a proper release process with versioning and release notes. AT ALL. You often need to mirror repos for your own project, and closely track what upstream projects are doing. git clone + go get for your big projects just doesn't work. This is incredibly problematic when developing big projects. A proper pkg solution should enforce versioning and release best practices.
  - jvehent 10y ago
    Godoc is searchable: https://godoc.org/?q=json+web+token https://godoc.org/?q=json+web+token
    - mfer 10y ago
      How do you find the main vs the forks of a package? What about useful metadata to help you make a decision? Compare godoc.org projects to https://crates.io/crates/bitflags https://crates.io/crates/bitflags or https://packagist.org/packages/masterminds/html5 https://packagist.org/packages/masterminds/html5. Look at the metadata to help you make a decision. Just the docs for the tip of master are far from what people expect.
      - themihai 10y ago
        You can see the number of imports and import graph on godoc. I don't see that on crates.io. You can also see if it's a fork on github. What is on crates.io link that is missing on Godoc? More colours? The package author chooses how much documentation is necessary for a given package. Given that html/js is a mess I expect more documentation to figure out how it works. Here is the godoc of a package with more text if that's what you are looking for http://godoc.org/google.golang.org/appengine/datastore http://godoc.org/google.golang.org/appengine/datastore On top of this the documentation is source code so you don't need a bunch of other fils to keep the documentation in sync.
  - aleksi 10y ago
    You mean http://www.gonuts.io http://www.gonuts.io?
    - the_duke 10y ago
      Yes, there are solutions out there, but the very first sentence on gonuts proves my point: "Serving 28 versions of 12 nuts published by 80 registered users." There's just very little adoption for these, and there won't be unless it's official.
  - theseoafs 10y ago
    Can you explain why the lack of a central package repository is an issue? All of the languages I use in my daily work have central package repositories, but I don't use them for discovery, I use google, GitHub, etc., because to feel comfortable using a package I need to answer some meta-questions about the package ("is this package used by a lot of people?", "is it updated frequently?", "are there are a lot of reported issues and do the owners respond to issues diligently?") It seems to me that while I'm on the GitHub page anyway, it's reasonably convenient to just copy-paste the URL in a file so I can pull in the package and use it. I can't imagine just using a package repo for discovering new packages, that would be tantamount to just pulling whatever random code someone wrote that looks like it might solve my problem.
    - steveklabnik 10y ago
      One small example: someone could delete that github repository, and you'd be hosed. But many centralized systems (like crates.io) do not let you remove packages. The only way that things accidentally break there is if the government gets involved.
      - theseoafs 10y ago
        That's certainly true -- unrelated to the discovery point I mentioned, but it is true. The different tradeoffs are well-understood at this point IMO.
      - themihai 10y ago
        As a package user you could use your own git mirroring server or just use a fork. Even simpler just vendor it and you are safe from package removal. On the other hand a central distribution model is more problematic. As package author I want a certain degree of control over my code. If crates.io gets compromissed or is down everyone suffers. If crates.io received a DMCA(happened on npm) my package can be removed. I put some effort into that package so if for some reasons I want to remove it it should be my choice. Why do want to keep it hostage if it's not yours? I though at leat Mozilla learned that distributed is better than centralized. Do you want a place to find all the rust packages? Make a search engine(see godoc.org). Less is more!
slrz 10y ago
The idea that somehow every single language and community needs its own crappy package management systems is just utterly broken. There's no reason you can't use the same package format and tools for code written in multiple languages. You might get some additional convenience by having small language-specific plugins (like the automatic dependency extractors in RPM) but that's just a tiny amount of the necessary tooling. The vast majority is not language-specific at all. With these language-community systems, there's also the problem of depending on code written in another language. My Go program might well depend on a C library, just as my C program can require a shell script.
- rat87 10y ago
  Unfortunately the idea that a new language meant for widespread use can ship without its own package management systems is even more broken. Generally languages need a good tool to allow (nested) dependencies that has a simple (preferably declarative) dependency file. Would it be nice to be able to have a cross language platform tool(jvm tools do generally play nice across languages in my understanding) like nix that also allows setting up other non language specific dependencies? Yes. But I'm not sure any are good enough/simple enough yet. Also language ecosystems tend to avoid non language dependencies (unless they're so common theyre typically installed with the language like lxml/libxml2) or have crappy ways to try to build c dependencies. So this is if not solved partially worked around. These package managers are mostly for development, not deployment although frequently they are also used to build or even deploy code. It would be nice for each language package manager to have plugins to generate self contained deb/rpm/ect. for deployment or even fancier to allow some dependencies to be (assuming it's not a language that prefers static linking/bundling) satisfied by system packages. But these take time and effort to write.

zzzcpan 10y ago

But the solutions don't offer much over "go get", what would be the point to use them?

the_duke 10y ago
I thoroughly disagree. The Golang ecosystem is in an incredibly weak state when you compare it with other modern languages. Major issues: -) Due to the lack of a proper package system, there's also no central pkg repository, which really hurts discoverabilty and growth of the ecosystem a lot. Just compare it to solutions like NPM for node, https://crates.io https://crates.io for Rust, Hackage for Haskell, etc... Github + https://godoc.org/ https://godoc.org/ is not a replacement for a proper package repository. -) Like I mentioned, way, way too many Go packages don't follow a proper release process with versioning and release notes. AT ALL. You often need to mirror repos for your own project, and closely track what upstream projects are doing. git clone + go get for your big projects just doesn't work. This is incredibly problematic when developing big projects. A proper pkg solution should enforce versioning and release best practices.
- jvehent 10y ago
  Godoc is searchable: https://godoc.org/?q=json+web+token https://godoc.org/?q=json+web+token
  - mfer 10y ago
    How do you find the main vs the forks of a package? What about useful metadata to help you make a decision? Compare godoc.org projects to https://crates.io/crates/bitflags https://crates.io/crates/bitflags or https://packagist.org/packages/masterminds/html5 https://packagist.org/packages/masterminds/html5. Look at the metadata to help you make a decision. Just the docs for the tip of master are far from what people expect.
    - themihai 10y ago
      You can see the number of imports and import graph on godoc. I don't see that on crates.io. You can also see if it's a fork on github. What is on crates.io link that is missing on Godoc? More colours? The package author chooses how much documentation is necessary for a given package. Given that html/js is a mess I expect more documentation to figure out how it works. Here is the godoc of a package with more text if that's what you are looking for http://godoc.org/google.golang.org/appengine/datastore http://godoc.org/google.golang.org/appengine/datastore On top of this the documentation is source code so you don't need a bunch of other fils to keep the documentation in sync.
- aleksi 10y ago
  You mean http://www.gonuts.io http://www.gonuts.io?
  - the_duke 10y ago
    Yes, there are solutions out there, but the very first sentence on gonuts proves my point: "Serving 28 versions of 12 nuts published by 80 registered users." There's just very little adoption for these, and there won't be unless it's official.
- theseoafs 10y ago
  Can you explain why the lack of a central package repository is an issue? All of the languages I use in my daily work have central package repositories, but I don't use them for discovery, I use google, GitHub, etc., because to feel comfortable using a package I need to answer some meta-questions about the package ("is this package used by a lot of people?", "is it updated frequently?", "are there are a lot of reported issues and do the owners respond to issues diligently?") It seems to me that while I'm on the GitHub page anyway, it's reasonably convenient to just copy-paste the URL in a file so I can pull in the package and use it. I can't imagine just using a package repo for discovering new packages, that would be tantamount to just pulling whatever random code someone wrote that looks like it might solve my problem.
  - steveklabnik 10y ago
    One small example: someone could delete that github repository, and you'd be hosed. But many centralized systems (like crates.io) do not let you remove packages. The only way that things accidentally break there is if the government gets involved.
    - theseoafs 10y ago
      That's certainly true -- unrelated to the discovery point I mentioned, but it is true. The different tradeoffs are well-understood at this point IMO.
    - themihai 10y ago
      As a package user you could use your own git mirroring server or just use a fork. Even simpler just vendor it and you are safe from package removal. On the other hand a central distribution model is more problematic. As package author I want a certain degree of control over my code. If crates.io gets compromissed or is down everyone suffers. If crates.io received a DMCA(happened on npm) my package can be removed. I put some effort into that package so if for some reasons I want to remove it it should be my choice. Why do want to keep it hostage if it's not yours? I though at leat Mozilla learned that distributed is better than centralized. Do you want a place to find all the rust packages? Make a search engine(see godoc.org). Less is more!

slrz 10y ago

The idea that somehow every single language and community needs its own crappy package management systems is just utterly broken. There's no reason you can't use the same package format and tools for code written in multiple languages. You might get some additional convenience by having small language-specific plugins (like the automatic dependency extractors in RPM) but that's just a tiny amount of the necessary tooling. The vast majority is not language-specific at all. With these language-community systems, there's also the problem of depending on code written in another language. My Go program might well depend on a C library, just as my C program can require a shell script.

rat87 10y ago
Unfortunately the idea that a new language meant for widespread use can ship without its own package management systems is even more broken. Generally languages need a good tool to allow (nested) dependencies that has a simple (preferably declarative) dependency file. Would it be nice to be able to have a cross language platform tool(jvm tools do generally play nice across languages in my understanding) like nix that also allows setting up other non language specific dependencies? Yes. But I'm not sure any are good enough/simple enough yet. Also language ecosystems tend to avoid non language dependencies (unless they're so common theyre typically installed with the language like lxml/libxml2) or have crappy ways to try to build c dependencies. So this is if not solved partially worked around. These package managers are mostly for development, not deployment although frequently they are also used to build or even deploy code. It would be nice for each language package manager to have plugins to generate self contained deb/rpm/ect. for deployment or even fancier to allow some dependencies to be (assuming it's not a language that prefers static linking/bundling) satisfied by system packages. But these take time and effort to write.