6 ms·

Here's an interesting portion of a Q&A panel from the same dotGo 2014 conference (http://dotgo.sourcegraph.com/post/99652344343/go-team-q-a-dependency-managemen

by sqs 12y ago

Here's an interesting portion of a Q&A panel from the same dotGo 2014 conference (http://dotgo.sourcegraph.com/post/99652344343/go-team-q-a-dependency-management-design-philosophy http://dotgo.sourcegraph.com/post/99652344343/go-team-q-a-de...) Q: There are several dependency management tools in the wild: godep, gpm, etc. Are there any plans to provide this functionality in the core? Brad Fitzpatrick: We don’t want to dictate a policy, so we hope the community fights it out and a victor emerges. Then maybe we’ll bless that one. Then if everyone likes it and it has been stable for a couple of years, maybe we’ll add it to the core. Brad Fitzpatrick: Part of the reason why we don’t care as much about dependency management inside Google is that we don’t use the go tool inside Google. Andrew Gerrand: The lack of versioning built into the Go tool incentivizes library authors to provide good, stable APIs.

kator 12y ago
Any clue as to what they do use internally?
- sqs 12y ago
  Yeah, check the comments at http://www.reddit.com/r/golang/comments/2j65lb/go_qa_at_dotgo_with_the_go_team_others_dep_mgmt/ http://www.reddit.com/r/golang/comments/2j65lb/go_qa_at_dotg... (specifically the blogspot link and Andrew Gerrand's (enneff's) comment).
- skj 12y ago
  Google has an internal build system that builds everything, and it's language independent. Sort of like a distributed make.
  - ithkuil 12y ago
    Some publicly available information: http://google-engtools.blogspot.ie/2011/08/build-in-cloud-how-build-system-works.html http://google-engtools.blogspot.ie/2011/08/build-in-cloud-ho... (https://news.ycombinator.com/item?id=2899467 https://news.ycombinator.com/item?id=2899467)
- jameskilton 12y ago
  They vendor everything.
  - spacemanmatt 12y ago
    "Vendor everything" was my conclusion to solving dependencies as generally as possible, while trying to knit PostgreSQL modules (locally produced schema chunks) and extensions with a base of versioned Rails apps.
  - willnorris 12y ago
    Yes, we do vendor everything, in that we have a snapshot of all of our dependencies in our source control system. But we do it across the entire codebase, not per project. That is, we typically only ever have a single version of a library for the entire company (with a few exceptions). If a project needs to update to a later version, they basically update everyone using that library. For widely used packages, this can sometimes be a time consuming process, but we've found it to be preferable to the alternative of having version conflicts all over the place. This is generally true not just for Go, but all languages. So the idea of a project needing to pin to a very specific version of a dependency and never update doesn't really fly.
    - Touche 12y ago
      That sounds like a wildly unproductive way to work. Discourages ever changing anything.
      - wmf 12y ago
        It sounds similar to the Linux kernel. If all the providers and consumers of an API are in the same repository, then you can change an API at any time as long as you update all consumers of the API at the same time.
      - skybrian 12y ago
        It does discourage upgrading until you really need it. On the other hand, if one person decides to do the work then everyone benefits.
erikb 12y ago
This is quite interesting, because after the Python fiasco in 2012/13 I thought a new language like Go would have learned from that and done that right from the beginning and I always thought Go did it. "We don't care" is even worse than "we just don't know how, yet".
- sqs 12y ago
  I didn't get the sense they were celebrating their lack of care, or that they chose not to care. (They didn't create Google's build system.) They were simply stating the reality.
- _ak 12y ago
  Different people have different requirements. It makes no sense to declare some tool to be THE STANDARD(TM) if it's of no use for a large proportion of their users. The way $GOPATH works and dependencies are managed is well-documented. Everybody is free to develop their own tooling. Right now, many people flock towards godep, but that might change in the future. Also, since this is only relevant during development and for compilation, getting it right is not as important as if you had to deploy every single one of your dependencies. With Go, you get one binary, and that's what you deploy.
  - ansible 12y ago
    And there are people like me who think that the programming language tooling shouldn't have to be tracking dependencies. If, for no other reason, than it is common to use multiple languages for a single project, and then a language-agnostic method should be used. I've leaned towards just having everything it our DVCS (git in our case). External libraries are handled using git subtree.
    - erikb 12y ago
      It is also using a defined way to handle dependencies. I have no problem with that either.
  - erikb 12y ago
jbooth 12y ago
Andrew Gerrand: The lack of versioning built into the Go tool incentivizes library authors to provide good, stable APIs. Are you kidding me??? So if some invariant behavior on an otherwise stable API changes, I don't know until runtime that a bunch of the code that I shipped, haven't changed, and then recompiled a month later has changed it's behavior?
- wtetzner 12y ago
  Yeah, this seems crazy to me. Also, honestly, while stable APIs can be nice, I would rather have people have the option to change the API in later versions, if it makes things better. But I want to be able to consciously decide to upgrade when I'm ready.
  - enneff 12y ago
    You do have that option. As I explained at the time (but this was not included in the live blog), the convention is to change the import path when the package API changes.
- enneff 12y ago
  If you're shipping serious code you should be vendoring your dependencies.
  - munificent 12y ago
    Why?
    - namsral 12y ago
      Because you want to have control over all software you're shipping to production.
      - simoncion 12y ago
        If "vendoring" precludes one from using a dependency installed on the system, then this practice is static linking all over again. Static linking has its place, but dynamic linking with sane versioning solves many problems.
munificent 12y ago
> Andrew Gerrand: The lack of versioning built into the Go tool incentivizes library authors to provide good, stable APIs. It certainly encourages stable APIs, but I don't see how making it very painful to iterate on your API is a strategy for good ones. My experience is that doing anything well requires the ability to gather and respond to feedback. If you can't iterate, then you're doomed to be stuck at 0.0.1 levels of quality.
- supersillyus 12y ago
  So, do you consider the Go1 compatibility guarantee to be a mistake? Most suggested stdlib or lang improvements are DOA for the time being as a result, which is annoying, but of course so too would be frequent breakages. I'm curious about your take, since you have some relevant experience.
  - munificent 12y ago
    > So, do you consider the Go1 compatibility guarantee to be a mistake? No, I think a language basically has to declare that level of compatibility for a major version. The important part is to get as much real-world feedback and iteration in as possible before you bang the 1.0 gong.
- deleted 12y ago
  [deleted]

by sqs 12y ago

kator 12y ago

Any clue as to what they do use internally?

sqs 12y ago
Yeah, check the comments at http://www.reddit.com/r/golang/comments/2j65lb/go_qa_at_dotgo_with_the_go_team_others_dep_mgmt/ http://www.reddit.com/r/golang/comments/2j65lb/go_qa_at_dotg... (specifically the blogspot link and Andrew Gerrand's (enneff's) comment).
skj 12y ago
Google has an internal build system that builds everything, and it's language independent. Sort of like a distributed make.
- ithkuil 12y ago
  Some publicly available information: http://google-engtools.blogspot.ie/2011/08/build-in-cloud-how-build-system-works.html http://google-engtools.blogspot.ie/2011/08/build-in-cloud-ho... (https://news.ycombinator.com/item?id=2899467 https://news.ycombinator.com/item?id=2899467)
jameskilton 12y ago
They vendor everything.
- spacemanmatt 12y ago
  "Vendor everything" was my conclusion to solving dependencies as generally as possible, while trying to knit PostgreSQL modules (locally produced schema chunks) and extensions with a base of versioned Rails apps.
- willnorris 12y ago
  Yes, we do vendor everything, in that we have a snapshot of all of our dependencies in our source control system. But we do it across the entire codebase, not per project. That is, we typically only ever have a single version of a library for the entire company (with a few exceptions). If a project needs to update to a later version, they basically update everyone using that library. For widely used packages, this can sometimes be a time consuming process, but we've found it to be preferable to the alternative of having version conflicts all over the place. This is generally true not just for Go, but all languages. So the idea of a project needing to pin to a very specific version of a dependency and never update doesn't really fly.
  - Touche 12y ago
    That sounds like a wildly unproductive way to work. Discourages ever changing anything.
    - wmf 12y ago
      It sounds similar to the Linux kernel. If all the providers and consumers of an API are in the same repository, then you can change an API at any time as long as you update all consumers of the API at the same time.
    - skybrian 12y ago
      It does discourage upgrading until you really need it. On the other hand, if one person decides to do the work then everyone benefits.

erikb 12y ago

This is quite interesting, because after the Python fiasco in 2012/13 I thought a new language like Go would have learned from that and done that right from the beginning and I always thought Go did it. "We don't care" is even worse than "we just don't know how, yet".

sqs 12y ago
I didn't get the sense they were celebrating their lack of care, or that they chose not to care. (They didn't create Google's build system.) They were simply stating the reality.
_ak 12y ago
Different people have different requirements. It makes no sense to declare some tool to be THE STANDARD(TM) if it's of no use for a large proportion of their users. The way $GOPATH works and dependencies are managed is well-documented. Everybody is free to develop their own tooling. Right now, many people flock towards godep, but that might change in the future. Also, since this is only relevant during development and for compilation, getting it right is not as important as if you had to deploy every single one of your dependencies. With Go, you get one binary, and that's what you deploy.
- ansible 12y ago
  And there are people like me who think that the programming language tooling shouldn't have to be tracking dependencies. If, for no other reason, than it is common to use multiple languages for a single project, and then a language-agnostic method should be used. I've leaned towards just having everything it our DVCS (git in our case). External libraries are handled using git subtree.
  - erikb 12y ago
    It is also using a defined way to handle dependencies. I have no problem with that either.
- erikb 12y ago

jbooth 12y ago

Andrew Gerrand: The lack of versioning built into the Go tool incentivizes library authors to provide good, stable APIs. Are you kidding me??? So if some invariant behavior on an otherwise stable API changes, I don't know until runtime that a bunch of the code that I shipped, haven't changed, and then recompiled a month later has changed it's behavior?

wtetzner 12y ago
Yeah, this seems crazy to me. Also, honestly, while stable APIs can be nice, I would rather have people have the option to change the API in later versions, if it makes things better. But I want to be able to consciously decide to upgrade when I'm ready.
- enneff 12y ago
  You do have that option. As I explained at the time (but this was not included in the live blog), the convention is to change the import path when the package API changes.
enneff 12y ago
If you're shipping serious code you should be vendoring your dependencies.
- munificent 12y ago
  Why?
  - namsral 12y ago
    Because you want to have control over all software you're shipping to production.
    - simoncion 12y ago
      If "vendoring" precludes one from using a dependency installed on the system, then this practice is static linking all over again. Static linking has its place, but dynamic linking with sane versioning solves many problems.

munificent 12y ago

> Andrew Gerrand: The lack of versioning built into the Go tool incentivizes library authors to provide good, stable APIs. It certainly encourages stable APIs, but I don't see how making it very painful to iterate on your API is a strategy for good ones. My experience is that doing anything well requires the ability to gather and respond to feedback. If you can't iterate, then you're doomed to be stuck at 0.0.1 levels of quality.

supersillyus 12y ago
So, do you consider the Go1 compatibility guarantee to be a mistake? Most suggested stdlib or lang improvements are DOA for the time being as a result, which is annoying, but of course so too would be frequent breakages. I'm curious about your take, since you have some relevant experience.
- munificent 12y ago
  > So, do you consider the Go1 compatibility guarantee to be a mistake? No, I think a language basically has to declare that level of compatibility for a major version. The important part is to get as much real-world feedback and iteration in as possible before you bang the 1.0 gong.
deleted 12y ago
[deleted]