3 ms·

The vendoring support in Cargo isn't really what I'm looking for. It's more "download all my deps from crates.io and make local copies" and it has various limit

The vendoring support in Cargo isn't really what I'm looking for. It's more "download all my deps from crates.io and make local copies" and it has various limitations I kept running into which I don't have time this morning to go back and document. It really felt like an afterthought and not at all like the third_party workflow that people who have worked with the Google monorepo would be used to.

steveklabnik 2y ago
I am interested in what vendoring means other than “put all of my dependencies’ code in my repo” but if you don’t have time, that’s chill. I’ve only seen open source projects using buck/bazel and haven’t ever seen google3, so I’m sure I’m missing something.
- CraigJPerry 2y ago
  Not OP but a difference is in who manages the updating of a vendored dep. You don’t want to update every time there’s a release, but you don’t want to never update either. If upstream (which you’ve vendored) releases a security fix, how does your system capture and act on that event? If vendoring just means we periodically pull a copy of upstream into our repo then you can have unbounded time when you don’t know there’s a vuln and therefore haven’t considered whether you need to act. This is obv different from the situation where we all just cargo install (without —locked) and different from c style dep mgmt where we get sec fixes for many libs via our OS patching.
  - steveklabnik 2y ago
    > If upstream (which you’ve vendored) releases a security fix, how does your system capture and act on that event? You still retain the Cargo.toml and Cargo.lock, so the exact same way as if you didn't vendor: `cargo-audit` would inform you, you'd update the version, and re-vendor.
    - CraigJPerry 2y ago
      It’s not how do you do that, it’s What (systemically) triggers you to do that? Are some developer(s) on the team responsible for subscribing to the relevant vuln lists and scanning them each day? Do you buy in some tooling?
      - steveklabnik 2y ago
        The cargo-audit I referred to in my previous post is that tooling, it's commonly run in CI regularly. But, also, this is pretty far afield from my original question: I understand why keeping copies of your dependencies can introduce various things you should handle, but my original question was "what is vendoring your dependencies if not 'keeping a copy of the source code of your dependencies in the repository'"? That's my understanding of the definition of "vendoring," so I was curious what my original parents' definition was.

steveklabnik 2y ago

I am interested in what vendoring means other than “put all of my dependencies’ code in my repo” but if you don’t have time, that’s chill. I’ve only seen open source projects using buck/bazel and haven’t ever seen google3, so I’m sure I’m missing something.

CraigJPerry 2y ago
Not OP but a difference is in who manages the updating of a vendored dep. You don’t want to update every time there’s a release, but you don’t want to never update either. If upstream (which you’ve vendored) releases a security fix, how does your system capture and act on that event? If vendoring just means we periodically pull a copy of upstream into our repo then you can have unbounded time when you don’t know there’s a vuln and therefore haven’t considered whether you need to act. This is obv different from the situation where we all just cargo install (without —locked) and different from c style dep mgmt where we get sec fixes for many libs via our OS patching.
- steveklabnik 2y ago
  > If upstream (which you’ve vendored) releases a security fix, how does your system capture and act on that event? You still retain the Cargo.toml and Cargo.lock, so the exact same way as if you didn't vendor: `cargo-audit` would inform you, you'd update the version, and re-vendor.
  - CraigJPerry 2y ago
    It’s not how do you do that, it’s What (systemically) triggers you to do that? Are some developer(s) on the team responsible for subscribing to the relevant vuln lists and scanning them each day? Do you buy in some tooling?
    - steveklabnik 2y ago
      The cargo-audit I referred to in my previous post is that tooling, it's commonly run in CI regularly. But, also, this is pretty far afield from my original question: I understand why keeping copies of your dependencies can introduce various things you should handle, but my original question was "what is vendoring your dependencies if not 'keeping a copy of the source code of your dependencies in the repository'"? That's my understanding of the definition of "vendoring," so I was curious what my original parents' definition was.