Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goop – Dependency Manager for Go

github.com

Post reply on HN
Print view View original

41–46 of 46 posts

Re: Goop – Dependency Manager for Go

#41

Post by jzelinskie »

grey-area wrote: post #37
jzelinskie wrote: post #33

Earlier quoted context omitted.

For git (and probably others) It actually looks for a "go1" tag, and if not there it uses the head of master. I honestly don't care for all these version managers. If I didn't trust the author of whatever library I'm pulling in to keep their API stable, then I wouldn't use that library or I'd preemptively fork. This is actually a language convention and if more people were familiar with it, there would be even less i…

You are arguing for versionless libraries? AFAIK the go maintainers tried that with golang itself in the beginning, and gave up on it, because it's not practical in real world use when APIs are changing quickly and outsiders want to know if they can update without breaking. There are very few libraries which have managed this in the past and have remained at version 1.x for their lifetime. It's interesting that go ge…

I don't think they've given up on the idea considering there still is no official version management. To give up would mean that they're doing something else and AFAIK this is still best practice. The early Go team did believe this would be an okay idea, but over time everyone has noticed that it may not be for the best. However, the Go team also punted on solving the problem while thinking that the community will figure something out. The problem is that "go get" is already built into our standard toolchain. The moment you start using a dependency manager, now the official toolchain workflow is broken and you've fragmented the ecosystem. If people really want a solution to this problem they need to prod the Go team and finally get an official decision made and merged into the go tool, rather than just creating their own binary.

Re: Goop – Dependency Manager for Go

#43

Post by grey-area »

jzelinskie wrote: post #41
grey-area wrote: post #37

Earlier quoted context omitted.

You are arguing for versionless libraries? AFAIK the go maintainers tried that with golang itself in the beginning, and gave up on it, because it's not practical in real world use when APIs are changing quickly and outsiders want to know if they can update without breaking. There are very few libraries which have managed this in the past and have remained at version 1.x for their lifetime. It's interesting that go ge…

I don't think they've given up on the idea considering there still is no official version management. To give up would mean that they're doing something else and AFAIK this is still best practice. The early Go team did believe this would be an okay idea, but over time everyone has noticed that it may not be for the best. However, the Go team also punted on solving the problem while thinking that the community will fi…

I don't think they've given up on the idea considering there still is no official version management.

Sorry, that wasn't clear, I was talking about the language itself - the language is now versioned, but it wasn't for initial releases - they had weekly snapshots, then moved to formal versioning and gave up on the idea of being version-less. See these slides about version 1:

http://talks.golang.org/2012/go1.slide

What holds for the language holds also for libraries I think - having explicit versioned releases and being able to sometimes break backwards compatibility is really useful, esp. if others can pin whatever version they import easily and migrate at their own pace.

I think it's good people are experimenting with pkg versioning - if someone comes up with an elegant solution and deals with most of the edge cases, it'll probably get into the bundled tools like go get eventually, or people will stop using go get and use another better tool. go get is not essential for fetching go libraries, it's just the blessed method.

Re: Goop – Dependency Manager for Go

#44

Post by nevir »

grey-area wrote: post #37
jzelinskie wrote: post #33

Earlier quoted context omitted.

For git (and probably others) It actually looks for a "go1" tag, and if not there it uses the head of master. I honestly don't care for all these version managers. If I didn't trust the author of whatever library I'm pulling in to keep their API stable, then I wouldn't use that library or I'd preemptively fork. This is actually a language convention and if more people were familiar with it, there would be even less i…

You are arguing for versionless libraries? AFAIK the go maintainers tried that with golang itself in the beginning, and gave up on it, because it's not practical in real world use when APIs are changing quickly and outsiders want to know if they can update without breaking. There are very few libraries which have managed this in the past and have remained at version 1.x for their lifetime. It's interesting that go ge…

I suspect it stems more from the Google origins than anything else.

Most of Google's code base is one big repository, and everyone is working at HEAD. It's nice not having to support a matrix of dependency versions, but that really only works when you can also modify downstream dependencies with ease.

That works within Google because there's a culture of constant maintenance; but out in the real world, you can't expect OSS package maintainers to be constantly active & willing to accept patches.

Re: Goop – Dependency Manager for Go

#45

Post by cstrahan »

grey-area wrote: post #31
raingrove wrote: post #13

Earlier quoted context omitted.

You are right. Unfortunately, constraints resolution isn't something that can be implemented in a practical manner until there is a standard versioning scheme (there isn't much you can do with git hashes) and a standard dependency manifest file that every go project adopts. Goop has `Goopfile.lock` and `goop exec`, inspired by Bundler's `Gemfile.lock` and `bundle exec`.

until there is a standard versioning scheme (there isn't much you can do with git hashes) Couldn't you use tags for versioning? Often people use tag v1.1.1 etc?

See: "and a standard dependency manifest file that every go project adopts"

You need some way to create a complete dependency graph for a given project. If your project has a list of its immediate dependencies, but those dependencies in turn require specific versions of other packages, how do know what those versions are? You need some consistent way of getting this metadata.

There are a couple solutions, but a few that come to mind: each project stores their deps metadata in a consistent location in their repo, or there's some central package repo (a la RubyGems) where such metadata can be queried.

For any solution to work, all of your dependencies (both direct and indirect) need to opt in to the same metadata scheme, or the system falls apart. Unfortunately, there isn't any consensus in the Go community on how to fix this.

This is what the parent meant by "there isn't much you can do with git hashes."

Re: Goop – Dependency Manager for Go

#46

Post by grey-area »

nevir wrote: post #44
grey-area wrote: post #37

Earlier quoted context omitted.

You are arguing for versionless libraries? AFAIK the go maintainers tried that with golang itself in the beginning, and gave up on it, because it's not practical in real world use when APIs are changing quickly and outsiders want to know if they can update without breaking. There are very few libraries which have managed this in the past and have remained at version 1.x for their lifetime. It's interesting that go ge…

I suspect it stems more from the Google origins than anything else. Most of Google's code base is one big repository, and everyone is working at HEAD. It's nice not having to support a matrix of dependency versions, but that really only works when you can also modify downstream dependencies with ease. That works within Google because there's a culture of constant maintenance; but out in the real world, you can't expe…

Yes, you're probably right, it does sound like they work this way internally, but it's not really practical if you have an open ecosystem with lots of different packages by authors who are not paid to maintain them. It'll be interesting to see if they bend on this and adopt some versioned solution.
Post reply on HN