5 ms·

Any clue as to what they do use internally?

by kator 12y ago

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.
      - noselasd 12y ago
        That sounds quite implausible. Sure, one person can go and upgrade the library. But I find it hard to believe that one person can go and fix up all the projects he's hardly ever heard of that depends on that library.
        skybrian 12y ago
        We have good tools for this. A Googler can create a patch that upgrades a library and run tests for all projects to see what breaks. The project owners review the changes. Of course, some upgrades are easier than others. In some ways this is similar to what Linux distros do, but sharing common source control, build system, and test runner makes it easier.
    - ninkendo 12y ago
      It also results in having a huge version control repo. From what I've heard, Google can't move to git because of this... they're stuck with Perforce because it's the only VCS that can support a repo of their size.
- solipsism 12y ago
  I'm going to guess you're a Rubyist. I had to look up what "vendor everything" referred to. There's a reasonably well referenced blog post by a Rubyist -- but only referenced by other Rubyists. I see that the Bundler tool looks for a 'vendor' subdirectory, so I'm going to guess that's how it became a part of the Ruby lexicon. Anyway, just wanted to point out that it's possible you're using Ruby lingo and not general-purpose tech terms. I could be wrong, maybe I just missed the boat. I think "bundle everything" might make sense to everybody, including Rubyists.
  - jleader 12y ago
    I remember reading about "vendor" branches in the cvs documentation (probably in the early 2000s), which if I recall correctly were trying to solve a similar problem to sub-modules in git. So I don't think the Rubyists invented the term.
    - djur 12y ago
      The Subversion book covers the concept of vendor branches extensively: http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.html http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.htm... That's where I first read the term, but it predates svn. As far as I know, it's been the common term for committing external dependencies to your own VCS for as long as there's been such a thing as a VCS.
  - lavamantis 12y ago
    We are Nodeists (not nudists - to the best of my knowledge) - we like to use the term "shrinkwrap."
    - jacques_chester 12y ago
      Shrinkwrap isn't quite the same. npm install --save seems to be the closest equivalent, based on discussions I've had with people. Vendoring means having the physical source code on hand. Not version numbers, not SHAs -- actual checked-out code.

Any clue as to what they do use internally?

by 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.
    - noselasd 12y ago
      That sounds quite implausible. Sure, one person can go and upgrade the library. But I find it hard to believe that one person can go and fix up all the projects he's hardly ever heard of that depends on that library.
      - skybrian 12y ago
        We have good tools for this. A Googler can create a patch that upgrades a library and run tests for all projects to see what breaks. The project owners review the changes. Of course, some upgrades are easier than others. In some ways this is similar to what Linux distros do, but sharing common source control, build system, and test runner makes it easier.
  - ninkendo 12y ago
    It also results in having a huge version control repo. From what I've heard, Google can't move to git because of this... they're stuck with Perforce because it's the only VCS that can support a repo of their size.
solipsism 12y ago
I'm going to guess you're a Rubyist. I had to look up what "vendor everything" referred to. There's a reasonably well referenced blog post by a Rubyist -- but only referenced by other Rubyists. I see that the Bundler tool looks for a 'vendor' subdirectory, so I'm going to guess that's how it became a part of the Ruby lexicon. Anyway, just wanted to point out that it's possible you're using Ruby lingo and not general-purpose tech terms. I could be wrong, maybe I just missed the boat. I think "bundle everything" might make sense to everybody, including Rubyists.
- jleader 12y ago
  I remember reading about "vendor" branches in the cvs documentation (probably in the early 2000s), which if I recall correctly were trying to solve a similar problem to sub-modules in git. So I don't think the Rubyists invented the term.
  - djur 12y ago
    The Subversion book covers the concept of vendor branches extensively: http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.html http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.htm... That's where I first read the term, but it predates svn. As far as I know, it's been the common term for committing external dependencies to your own VCS for as long as there's been such a thing as a VCS.
- lavamantis 12y ago
  We are Nodeists (not nudists - to the best of my knowledge) - we like to use the term "shrinkwrap."
  - jacques_chester 12y ago
    Shrinkwrap isn't quite the same. npm install --save seems to be the closest equivalent, based on discussions I've had with people. Vendoring means having the physical source code on hand. Not version numbers, not SHAs -- actual checked-out code.