4 ms·

How is copying better than dependencies in this regard? You presumably need legal signoff either way. I wasn't referring to copying that I would do myself, but

How is copying better than dependencies in this regard? You presumably need legal signoff either way. I wasn't referring to copying that I would do myself, but copying that other crates would do. That is, if a crate only needs a little bit from a little dependency, then copying it into their crate can make everyone else's life easier (obviously taking licensing into consideration when doing so). In short, the context here was the bytes crate, which is fairly tiny. If rust is going to insist on not including the bytes crate, or a copy of it, in the standard library, then I would hope others that consume it would consider embedding a snapshot of it into their own crate for their own, private use so that I don't have to worry about it. I'm well aware there's a fine line here, hence my reference to the Go proverb.

steveklabnik 9y ago
> so that I don't have to worry about it. What would you be worrying about?
- binarycrusader 9y ago
  The short version is that a component distributed with an embedded copy of its dependencies means a single legal review since it's a snapshot in time of a particular version of that component and its dependencies. A component that instead references its dependencies and that have their own release schedule/versions, etc. requires a legal review for that component and each of its dependencies. This has been true at multiple employers I've worked for, so seems unlikely to be a consideration unique to my current employer.
  - pcwalton 9y ago
    Again, that's what the Rust Platform is for. It's a better solution than copying code, because it doesn't throw away all of the benefits of Cargo just to make some legal policies at some large companies a little easier.
    - binarycrusader 9y ago
      We're going to have to agree to disagree. This is where I actually prefer Go's "vendor" approach to dependencies. It would be great if rust / cargo eventually had the same and more authors adopted it or simply copied their little dependencies instead of having external dependencies on them. Something like this proposed command, except for crate maintenance instead of distribution: https://users.rust-lang.org/t/cargo-cook-subcommand/10288 https://users.rust-lang.org/t/cargo-cook-subcommand/10288
      - pcwalton 9y ago
        I sincerely hope that people never start copying code into their packages. I see virtually no upsides, except for making it easier to dodge bureaucratic hurdles at some big companies, and a huge number of downsides (basically forgoing all the benefits of Cargo).
      - eddyb 9y ago
        FWIW `cargo vendor` already exists, just not part of Cargo itself, but rather a tool by one of the core devs. It's even used for releasing the official Rust tarballs as we now employ crates.io dependencies in the standard library and the compiler.
        tmzt 9y ago
        Does it do more than using relative paths in a Cargo.toml would do? I think this thread is about copying and pasting code versus using a small library in the Go case, which might be a philosphical difference with Rust. It might help to point out that vendored crates are compiled from source making the required review process referenced by that poster just as possible with server crates.
  - steveklabnik 9y ago
    Gotcha, thanks.

steveklabnik 9y ago

> so that I don't have to worry about it. What would you be worrying about?

binarycrusader 9y ago
The short version is that a component distributed with an embedded copy of its dependencies means a single legal review since it's a snapshot in time of a particular version of that component and its dependencies. A component that instead references its dependencies and that have their own release schedule/versions, etc. requires a legal review for that component and each of its dependencies. This has been true at multiple employers I've worked for, so seems unlikely to be a consideration unique to my current employer.
- pcwalton 9y ago
  Again, that's what the Rust Platform is for. It's a better solution than copying code, because it doesn't throw away all of the benefits of Cargo just to make some legal policies at some large companies a little easier.
  - binarycrusader 9y ago
    We're going to have to agree to disagree. This is where I actually prefer Go's "vendor" approach to dependencies. It would be great if rust / cargo eventually had the same and more authors adopted it or simply copied their little dependencies instead of having external dependencies on them. Something like this proposed command, except for crate maintenance instead of distribution: https://users.rust-lang.org/t/cargo-cook-subcommand/10288 https://users.rust-lang.org/t/cargo-cook-subcommand/10288
    - pcwalton 9y ago
      I sincerely hope that people never start copying code into their packages. I see virtually no upsides, except for making it easier to dodge bureaucratic hurdles at some big companies, and a huge number of downsides (basically forgoing all the benefits of Cargo).
    - eddyb 9y ago
      FWIW `cargo vendor` already exists, just not part of Cargo itself, but rather a tool by one of the core devs. It's even used for releasing the official Rust tarballs as we now employ crates.io dependencies in the standard library and the compiler.
      - tmzt 9y ago
        Does it do more than using relative paths in a Cargo.toml would do? I think this thread is about copying and pasting code versus using a small library in the Go case, which might be a philosphical difference with Rust. It might help to point out that vendored crates are compiled from source making the required review process referenced by that poster just as possible with server crates.
- steveklabnik 9y ago
  Gotcha, thanks.