4 ms·

> If you aren't committing your dependencies then you're doing it wrong. Disagree strongly (and hate absolutes like "doing it wrong"). Their metadata, yes, by

> If you aren't committing your dependencies then you're doing it wrong. Disagree strongly (and hate absolutes like "doing it wrong"). Their metadata, yes, by all means, commit that. There is absolutely no reason, however, to have the source code for a dependency in my tree, Go or not. Give me a binary I can link against, or at least the temporary source in a .gitignored location, and let's call it a day. When I want to bump to a new version my commit should be a one-line version bump in a metadata file, not the entirety of the upstream changes as a commit. I've seen a sub-1MLoC project take 10 minutes just to clone. Internally! You're telling me you want to add all the LoC and flattened change history of your dependencies in your repo? Egads, no thanks! Where do you draw that line? Do you commit glibc? There's just no reason to store that history unless you are in the business of actively debugging your dependencies and fixing the problems yourself, rather than identifying the issue and rolling back to a previous version after reporting the problem upstream. I guess it's paying your engineers to fix libopenal versus paying your engineers to work on your product; one's a broken shop, the other isn't. Some people will feel it's one, some the other.

krallin 13y ago
I'm not entirely familiar with how go dependencies work, but does using git submodules for the dependencies with go make sense?
- bjeanes 13y ago
  Almost. `go get` will not resolve your sub-moduled dependencies. It'll work well enough for developing your library, but will break when people try to consume your library (at least, without git cloning it)
bjeanes 13y ago
Thank you. It makes me weep when I hear gophers telling me to vendor all my dependencies. That is insane. Completely insane.
- kkowalczyk 13y ago
  Actually what is insane is to have your production code do anything else. "pip install foo" and similar schemes open your code up to the following problems: - incompatibilities that were introduced in the version 1.2.1 while you've only tested your code with 1.2 - the host is down so you can't compile your own code because your dependency is not available - the host is hacked and "foo" was replaced with "malicious foo" - exponential increase of testing (you really should test with all version of your dependencies you use) Ultimately, I don't understand the doom and gloom point of view. C, C++, Java, C# etc. programmers have been pulling dependencies in their repos for ages. In my SumatraPDF I have 12 dependencies. I certainly prefer to manually update them from time to time than to have builds that work on my machine but fail for other people or many other problems that are a result of blindly pulling third party code.
  - lucian1900 13y ago
    > - incompatibilities that were introduced in the version 1.2.1 while you've only tested your code with 1.2 Which is why you pin dependencies to specific versions. > - the host is down so you can't compile your own code because your dependency is not available Which is why you have (caching) proxy and use mirrors. > - the host is hacked and "foo" was replaced with "malicious foo" Which is why you use GPG signing. (sadly, Python lacks in this respect). > - exponential increase of testing (you really should test with all version of your dependencies you use) Which is why you only use a specific version.
  - d0mine 13y ago
    - you can freeze the version: foo==1.2.1 - you don't need the internet to install dependencies. There are many options e.g., a locally cached tarball will do (no need to download the same file multiple times). Note: your source tree is not the place to put it (the same source can be built, tested, staged, deployed using different dependencies versions e.g., to support different distributions where different versions are available by default) - if your build infrastructure is compromised; you have bigger problems than just worrying about dependencies - you don't need to pull dependencies and dependencies of dependencies, etc into your source tree to keep the size of the test matrix in check even if you decided to support only a single version for each your dependencies. As usual different requirements may lead to different trades off. There could be circumstances where to vendor dependencies is a valid choice but not due to the reasons you provided
skybrian 13y ago
No really! Go isn't like other languages. You have to think differently. Please try it! There's no such thing as, say, Maven binary dependencies for Java. If you don't check in the source code for your dependencies, your team member won't get the same version as you have and builds won't be reproducible. You won't be able to go back to a previous version of your app and rebuild it, because the trunk of your dependencies will have changed. By checking in the source code you're avoid a whole lot of hurt. Checking in source is okay because Go source files are small and the compiler is fast. There isn't a huge third-party ecosystem for Go yet.
- tiredofcareer 13y ago
  > There's no such thing as, say, Maven binary dependencies for Java. I'm saying there should be, but not necessarily the same thing. That's my entire point. I'm also not a fan of the "you have a dissimilar opinion to mine, so obviously you've never used Go properly" attitude in this thread. One way to read your last is that I've never used Go at all, though I'm giving you the benefit of the doubt and assuming you meant used Go properly. Either way, I don't get the condescension of assuming I'm unaware of everything you're explaining to me simply because I have an opinion that is different than yours. Especially since half of your comment is repeating things to me that I said earlier.
  - skybrian 13y ago
    Maybe it sounds like condescension. I was in the same place at the beginning. No exceptions? No generics? Heresy. How dare you Go people ignore my many years of experience? I wrote a few rants to the mailing list, which were basically ignored. The reason I assume you haven't used Go much is that your examples of problems with checking stuff in aren't examples of problems happening in Go. It's an analogy with other languages and other environments. Such arguments don't seem to get very far. Maybe it won't scale and something will have to give. I expect the Go maintainers will find their own solution when it happens, and it won't look like Maven or traditional shared libraries. (If anything, it might be by replacing Git/hg with something that scales better.)
- pjmlp 13y ago
markokocic 13y ago
You already have that in Javaland. It's called maven, and it allows you to change one number in one file to upgrade the dependency version. Clojure also has that with Leiningen.
wvenable 13y ago
> There is absolutely no reason, however, to have the source code for a dependency in my tree, Go or not. Disk space is cheap; much cheaper than time needed to fix something if it goes to hell and some remote repository isn't available.
- happy_dino 13y ago
  Interestingly, the only ecosystem which suffers from such issues is Go.

krallin 13y ago

I'm not entirely familiar with how go dependencies work, but does using git submodules for the dependencies with go make sense?

bjeanes 13y ago
Almost. `go get` will not resolve your sub-moduled dependencies. It'll work well enough for developing your library, but will break when people try to consume your library (at least, without git cloning it)

bjeanes 13y ago

Thank you. It makes me weep when I hear gophers telling me to vendor all my dependencies. That is insane. Completely insane.

kkowalczyk 13y ago
Actually what is insane is to have your production code do anything else. "pip install foo" and similar schemes open your code up to the following problems: - incompatibilities that were introduced in the version 1.2.1 while you've only tested your code with 1.2 - the host is down so you can't compile your own code because your dependency is not available - the host is hacked and "foo" was replaced with "malicious foo" - exponential increase of testing (you really should test with all version of your dependencies you use) Ultimately, I don't understand the doom and gloom point of view. C, C++, Java, C# etc. programmers have been pulling dependencies in their repos for ages. In my SumatraPDF I have 12 dependencies. I certainly prefer to manually update them from time to time than to have builds that work on my machine but fail for other people or many other problems that are a result of blindly pulling third party code.
- lucian1900 13y ago
  > - incompatibilities that were introduced in the version 1.2.1 while you've only tested your code with 1.2 Which is why you pin dependencies to specific versions. > - the host is down so you can't compile your own code because your dependency is not available Which is why you have (caching) proxy and use mirrors. > - the host is hacked and "foo" was replaced with "malicious foo" Which is why you use GPG signing. (sadly, Python lacks in this respect). > - exponential increase of testing (you really should test with all version of your dependencies you use) Which is why you only use a specific version.
- d0mine 13y ago
  - you can freeze the version: foo==1.2.1 - you don't need the internet to install dependencies. There are many options e.g., a locally cached tarball will do (no need to download the same file multiple times). Note: your source tree is not the place to put it (the same source can be built, tested, staged, deployed using different dependencies versions e.g., to support different distributions where different versions are available by default) - if your build infrastructure is compromised; you have bigger problems than just worrying about dependencies - you don't need to pull dependencies and dependencies of dependencies, etc into your source tree to keep the size of the test matrix in check even if you decided to support only a single version for each your dependencies. As usual different requirements may lead to different trades off. There could be circumstances where to vendor dependencies is a valid choice but not due to the reasons you provided

skybrian 13y ago

No really! Go isn't like other languages. You have to think differently. Please try it! There's no such thing as, say, Maven binary dependencies for Java. If you don't check in the source code for your dependencies, your team member won't get the same version as you have and builds won't be reproducible. You won't be able to go back to a previous version of your app and rebuild it, because the trunk of your dependencies will have changed. By checking in the source code you're avoid a whole lot of hurt. Checking in source is okay because Go source files are small and the compiler is fast. There isn't a huge third-party ecosystem for Go yet.

tiredofcareer 13y ago
> There's no such thing as, say, Maven binary dependencies for Java. I'm saying there should be, but not necessarily the same thing. That's my entire point. I'm also not a fan of the "you have a dissimilar opinion to mine, so obviously you've never used Go properly" attitude in this thread. One way to read your last is that I've never used Go at all, though I'm giving you the benefit of the doubt and assuming you meant used Go properly. Either way, I don't get the condescension of assuming I'm unaware of everything you're explaining to me simply because I have an opinion that is different than yours. Especially since half of your comment is repeating things to me that I said earlier.
- skybrian 13y ago
  Maybe it sounds like condescension. I was in the same place at the beginning. No exceptions? No generics? Heresy. How dare you Go people ignore my many years of experience? I wrote a few rants to the mailing list, which were basically ignored. The reason I assume you haven't used Go much is that your examples of problems with checking stuff in aren't examples of problems happening in Go. It's an analogy with other languages and other environments. Such arguments don't seem to get very far. Maybe it won't scale and something will have to give. I expect the Go maintainers will find their own solution when it happens, and it won't look like Maven or traditional shared libraries. (If anything, it might be by replacing Git/hg with something that scales better.)
pjmlp 13y ago

markokocic 13y ago

You already have that in Javaland. It's called maven, and it allows you to change one number in one file to upgrade the dependency version. Clojure also has that with Leiningen.

wvenable 13y ago

> There is absolutely no reason, however, to have the source code for a dependency in my tree, Go or not. Disk space is cheap; much cheaper than time needed to fix something if it goes to hell and some remote repository isn't available.

happy_dino 13y ago
Interestingly, the only ecosystem which suffers from such issues is Go.