Stories with similar links:
- SFTPGo: a Golang performance story and some questions via inactive-user 3 years ago | 7 points | no comments
- Racket2 possibilities via inactive-user 4 years ago | 20 points | 9 comments
- PostScript and Interpress: a comparison (1985) via zge 4 years ago | 4 points | no comments
- Origins of the finger command via calvin 5 years ago | 21 points | no comments
- The NetHack DevTeam is happy to announce the release of NetHack 3.6.1 via intercal 5 years ago | 21 points | 5 comments
- CVE-2017-17482: OpenVMS Security Notice for local privilege escalation via dege 5 years ago | 4 points | no comments
- Eve (programming language) is winding down via roryokane 5 years ago | 45 points | 12 comments
- Go 1.10 Beta 1 is released via av 5 years ago | 6 points | no comments
- Termination of the certificates business of Startcom via calvin 5 years ago | 20 points | 1 comment
- A new Common Lisp compiler/interpreter in Prolog via rogersm 5 years ago | 11 points | 2 comments
- Faster blame on hg.mozilla.org (2016) via JordiGH 5 years ago | 4 points | no comments
- Sequel 5.0.0 Released authored by jeremyevans 6 years ago | 13 points | 1 comment
- First Language (1998) via yumaikas 6 years ago | 1 point | no comments
- Redis 4.0.0 GA via fs111 6 years ago | 12 points | 1 comment
- mblaze 0.1, a Maildir-focused command line mail client via duncaen 6 years ago | 23 points | 1 comment
- Concerns about Kubernetes Community newcomers via devth 6 years ago | 2 points | 1 comment
- Shen has been ported to C via bsima 6 years ago | 3 points | no comments
- Vitaly Slobodin steps down as PhantomJS maintainer because of headless Chrome via koehr 6 years ago | 3 points | 2 comments
- Symantec again caught issuing suspicious certificates, this time for example.com via kb 6 years ago | 15 points | 1 comment
- Ansible: New RCs for Security Bug CVE-2016-9587 via ChrisShort 6 years ago | 1 point | no comments
- Mercurial 4.0 Sprint Notes via ngoldbaum 6 years ago | 14 points | 3 comments
- Apple's response to the WoSign incidents via inactive-user 6 years ago | 17 points | 6 comments
- Happy 25th birthday Linux via mjturner 7 years ago | 7 points | 1 comment
- Incidents involving the CA WoSign via lattera 7 years ago | 16 points | 2 comments
- Vim 8.0 pre-announcement via romanzolotarev 7 years ago | 21 points | 7 comments
- Buford v0.7.0 Apple Push Notifications for Go 1.6 and HTTP/2 authored by nathany 7 years ago | 2 points | no comments
- Go 1.7 Beta 1 released via inactive-user 7 years ago | 12 points | no comments
- Linus hacks fsck to recover deleted files (1993) via pushcx 7 years ago | 2 points | no comments
- Alpha release of Servo to be released in June via ane 7 years ago | 29 points | 7 comments
- Git integrity via effdee 7 years ago | 28 points | 2 comments
- Multiple Ruby on Rails vulnerabilities via jasper 7 years ago | 3 points | 1 comment
- Go 1.5.3 is released via luiz 7 years ago | 8 points | no comments
- Go 1.6 Beta 1 is released via nathany 7 years ago | 12 points | 2 comments
- Phoenix 1.1 Released via bratsche 7 years ago | 19 points | no comments
- Go 1.5.2 is released via nathany 7 years ago | 9 points | 5 comments
- Standardising racket's threading macros via zem 7 years ago | 6 points | no comments
- Password Hashing Competition Winner: Argon2 via jcs 8 years ago | 15 points | no comments
- What is a closure? via rubenbarroso 8 years ago | 7 points | no comments
- Linux futex_wait bug via SeanTAllen 8 years ago | 12 points | no comments
- JMH vs Caliper reference thread (JVM micro-benchmarking) via tobym 8 years ago | 4 points | no comments
- [release] Redis 3.0.0 is out. via joshuacc 8 years ago | 10 points | 3 comments
- The RabbitMQ Team is Hiring - Remote Workers Accepted via old_sound 8 years ago | 2 points | no comments
- Go 1.4.1 Released via mreedell 8 years ago | 8 points | no comments
- comment on adding conditionals to configuration languages via stuntgoat 8 years ago | 1 point | no comments
- Choosing hardware to minimize latency via tobym 8 years ago | 3 points | no comments
- Rack, Change of Maintainer & Status via pushcx 9 years ago | 1 point | no comments
- Play 2.3.0 Is Released via kellogh 9 years ago | 1 point | no comments
- goroutines management via pyk 9 years ago | 1 point | no comments
- Rails Directory Traversal Vulnerability With Certain Route Configurations (CVE-2014-0130) via jcs 9 years ago | 1 point | no comments
- Proposal to remove StartCom from Mozilla CA truststore via hdevalence 9 years ago | 8 points | no comments
- A Simple Run Time Comparison Of AWKs Running A Genetic Algorithm via kmatt 9 years ago | 4 points | no comments
- Dotty open-sourced, research platform for new language concepts and compiler technologies for Scala via tobym 9 years ago | 9 points | 1 comment
- RubySec Summary of CVE-2013-6393 aka "you're probably vulnerable" via jcs 9 years ago | 3 points | no comments
- GHC (the standard Haskell compiler) gets first class iOS support via rbxbx 10 years ago | 5 points | no comments
- Play Framework - async by default via tobym 10 years ago | 2 points | no comments
- Multiple vulnerabilities in parameter parsing in Action Pack (Rails) (CVE-2013-0156) via jcs 10 years ago | 5 points | 1 comment
- golang-weekly issue #4 via nilmethod 11 years ago | 3 points | no comments
- Android 4.1 source code released via lynge 11 years ago | 4 points | 2 comments
It is interesting that they consider the dependencies of a library to almost be a non-issue (so far at least…the conversation is obviously ongoing).
I was also somewhat surprised to read that they have all their Go code in a single giant internal repo. That seems awful to me for some reason.
[Comment removed by author]
[Comment removed by author]
[Comment removed by author]
From what I gather “one giant Perforce repository with all code used in the company” is a surprisingly common version-control model at large companies.
[Comment removed by author]
And Facebook too. They rely on a single company-wide Mercurial repository.
We do that at my company (on a much smaller scale than Google) and I there are a lot of benefits. All our services and shared library code is in the same repo. It means every commit to the repo leaves every service fully in sync with one another for interface and data versions - no dependency management needed. It also makes git bisect awesome for bug tracking since all our code builds reliabily at every commit you bisect to.
Also it implies shared code ownership which I like. Anyone can fix anything and run all the tests for all the services at once and know nothing is broken.
Agree. Not sure why the title doesn’t use at least scare quotes for “solution”:
Basically they are saying “We put every single piece of code we need into a global repository, and pretty much don’t care about anyone not doing this. Let’s just standardize some of the dirty hacks and workarounds seen in the wild so that we can keep not caring about it.”
It scares the hell out of me when I imagine inexperienced people learning Go and thinking that this is the best way to manage dependencies in 2015.
They are not alone in doing this, contrary to what you wrote. Facebook does it too, with very much success.
I don’t think this is a hack. I’d even go as far as saying that the hack is dependency management tools like Python’s pip, Ruby’s Bundler and Node’s npm. I’ve been used these tools for a long time, and unlike you, I was not convinced. Vendoring in a monolithic company-wide repository seems to me a very reasonable and efficient approach.
So what? They can do whatever they want. That’s not the issue.
Where did I write that?
You are basically saying that some of the worst dependency management tools ever invented are even worse than not doing any kind of dependency management?
I don’t think many people would disagree with that.
I was replying to the part of your comment where you write “and [they] pretty much don’t care about anyone not doing this”. But you’re right in saying their choice is probably independent of what other companies do.
My mistake. I misread your comment. Sorry for that.
What dependency management tools would you recommend as good examples?
It’s not their Go code, Google keep all their code in a single epic repository.
This is a terrible idea (as others have noted). Vendoring is a workaround for the current lack of Go tooling for dependency management, it is not the solution to it.
Nah. Vendoring is a totally reasonable, maybe the best solution to the problem of dependency management. The devil’s in the details, of course.
Of course, I disagree with vendoring being a hack. Would you seriously argue that the entire Google and Facebook codebase is founded on a hack? That said, I’d be curious to know why it is hack according to you.
Facebook was written in PHP. That’s pretty much the definition of a hack.
I’m fine with vendoring.. but a real headache with this approach is the import path rewriting. Nothing is scarier than adding source code to your repo, trying to check if it has been modified and seeing a huge diff. I’m curious why they wouldn’t go the multiple GOPATH direction, as it at least leaves vendored code unmodified until the go tool is drastically improved.
I agree. Vendoring is great, but import path rewriting can be scary. Ideally, I’d prefer vendoring without any import path rewriting.
Exactly. That’s how the C/C++/Rust/npm/whatehaveyou projects I’ve worked on have done. Unfortunately the go tool enforces this GOPATH nonsense that has mostly ruined any chances of getting reasonable vendoring.