4 ms·

Please don't remove vendoring...

by marcrosoft 9y ago

LaGrange 9y ago
Yeah, this. You want reproducible builds? Vendor your crap. Check it into your repository. Live free.
- hota_mazi 9y ago
  Or adopt a system with a sane versioning system and immutable artifacts, e.g. Maven Central.
  - merb 9y ago
    which still means that your ci needs to download this stuff. with vendor it is already checked it. consider builds on docker etc, where build caching is hard. go is a breeze. build takes like half a second because everything is already there. mvn will first download the world. I'm a scala developer and sbt will probably take like 10 minutes just downloading stuff, if a cache missed (even with a local proxy).
    - pjmlp 9y ago
      I wonder how it is possible to take 10 minutes, unless it is downloading directly from internet. We always have internal Plexus mirrors, and the Jenkins servers have their global .m2 local repository. Even big JEE applications barely take more than 5 minutes to build. The only build system I really dislike are Android builds with Gradle, trying to beat C++ compilation times.
      - merb 9y ago
        well sbt uses ivy which is way slower than maven, when it comes to resolving stuff.
  - LaGrange 9y ago
    First things first, Maven's config files are an elaborate form of torture. Second, there is no such thing as remote artifacts that are immutable. Check your shit into your git repository. And managing that becomes a problem, you've already done goofed up and have too many dependencies, and it's unlikely there's _anything_ reproducible about your software.
    - hota_mazi 9y ago
      > Second, there is no such thing as remote artifacts that are immutable. And yet, that's exactly what Maven Central artifacts are. And why Maven Central is rock solid for reproducible builds while supporting versioning.
kardianos 9y ago
Vendoring is here to stay.
joeshaw 9y ago
I'm fine with vendoring going away as long as we can check these new modules into version control and have vgo use them. Adding a caching proxy adds too much infrastructure for most folks, and without it you can't have reproducible and available builds. I like Go's distributed package imports (even if everyone just uses Github), but it means you're distributing single points of failure all over the place. Vendoring (whether source or modules) solves this problem.

Please don't remove vendoring...

LaGrange 9y ago

Yeah, this. You want reproducible builds? Vendor your crap. Check it into your repository. Live free.

hota_mazi 9y ago
Or adopt a system with a sane versioning system and immutable artifacts, e.g. Maven Central.
- merb 9y ago
  which still means that your ci needs to download this stuff. with vendor it is already checked it. consider builds on docker etc, where build caching is hard. go is a breeze. build takes like half a second because everything is already there. mvn will first download the world. I'm a scala developer and sbt will probably take like 10 minutes just downloading stuff, if a cache missed (even with a local proxy).
  - pjmlp 9y ago
    I wonder how it is possible to take 10 minutes, unless it is downloading directly from internet. We always have internal Plexus mirrors, and the Jenkins servers have their global .m2 local repository. Even big JEE applications barely take more than 5 minutes to build. The only build system I really dislike are Android builds with Gradle, trying to beat C++ compilation times.
    - merb 9y ago
      well sbt uses ivy which is way slower than maven, when it comes to resolving stuff.
- LaGrange 9y ago
  First things first, Maven's config files are an elaborate form of torture. Second, there is no such thing as remote artifacts that are immutable. Check your shit into your git repository. And managing that becomes a problem, you've already done goofed up and have too many dependencies, and it's unlikely there's _anything_ reproducible about your software.
  - hota_mazi 9y ago
    > Second, there is no such thing as remote artifacts that are immutable. And yet, that's exactly what Maven Central artifacts are. And why Maven Central is rock solid for reproducible builds while supporting versioning.

kardianos 9y ago

Vendoring is here to stay.

joeshaw 9y ago

I'm fine with vendoring going away as long as we can check these new modules into version control and have vgo use them. Adding a caching proxy adds too much infrastructure for most folks, and without it you can't have reproducible and available builds. I like Go's distributed package imports (even if everyone just uses Github), but it means you're distributing single points of failure all over the place. Vendoring (whether source or modules) solves this problem.