5 ms·

> It is true that if you don't have dependencies, "cargo build" will go get them, but if you don't, then it shouldn't. The main problem is you can't download d

by dozzie 11y ago

> It is true that if you don't have dependencies, "cargo build" will go get them, but if you don't, then it shouldn't. The main problem is you can't download dependencies separately from compiling your code. It should never be the same step. Even pip had it mostly correct, by providing an option to disable network communication. It is somewhat mitigated by documentation mentioning where the downloaded dependencies are put, so you can do all that manually. This sucks balls heavily. > Yes, Cargo builds itself with Cargo, so you need to get a previous Cargo. The binary is very much not 'random'. It's fetched outside of regular downloading you do on tarball. You have no control over where is it downloaded from. It means it's pretty much random for your purposes. Heck, it would be even unexpected, if I wasn't used to developers not understanding the difference between building and downloading software. But this is not the main point. Cargo should not need already compiled Cargo to build itself. This is ridiculous. I understand that every good compiler is built with the very same compiler you're building, but look at how they do that: by bootstrapping. Not so much with Cargo. Who ever thought it as a valid idea?

steveklabnik 11y ago
> It should never be the same step. This is just going to be a preference then. I much prefer not having to type two things to do what's conceptually one: please build my code. "cargo fetch" means you don't have to do the download step manually. IE, you _can_ do it in two commands if you'd like. > It means it's pretty much random for your purposes. We are just going to have to agree to disagree on this one. First of all, you _already_ need an equally 'random' binary: rustc itself. Which is also bootstrapped. Second, it's not clear to me why bootstrapping is valid for a compiler, but not for any other kind of project. Cargo is a build system, written in Rust, so it uses Rust's build system.
- dozzie 11y ago
  > This is just going to be a preference then. No, it is not. * It's not always that you have internet connection when building your code. * It's not always that you have access to the website code is downloaded from (websites break, and companies have different policies about internet), and even if you do, you don't always have it direct (e.g. proxy). * And at the last, people will build code for various purposes, including building packages. Building a package should be a repeatable operation and should always use only clean source (no artifacts from previous builds), and downloading random things on every build from clean source is very easy way to break the process. >> It means it's pretty much random for your purposes. > We are just going to have to agree to disagree on this one. First of all, you _already_ need an equally 'random' binary: rustc itself. No. I downloaded Rust compiler myself (or had it installed from a package). I controlled that, it didn't hit me in my face unexpectedly. > Which is also bootstrapped. s/also//. Cargo is not bootstrapped, because it needs pre-built Cargo to build itself. Compare this to Rust compiler: you start with nothing but C(++? I don't remember) compiler, and end with Rust compiler. No intermediate download involved. > Second, it's not clear to me why bootstrapping is valid for a compiler, but not for any other kind of project. Cargo is a build system, written in Rust, so it uses Rust's build system. It's not invalid, quite the contrary. It's just Cargo doesn't boostrap itself out of clean code. It's that simple. I wouldn't have as big problem with it if its build process produced an intermediate, crippled Cargo binary. I would then complain about requiring external dependencies to be downloaded (in contrast to included), but that would be difference on strategy preferences.
  - vvanders 11y ago
    Going to have to agree with dozzie here, he's right on almost all accounts. There's a ton of things I like about Rust but the points he outlined above are things that I've seen very much impede the adoption of Rust into some environments that have similar restrictions(no download on build, build from source without binaries) for security and reproducibility reasons.
    - steveklabnik 11y ago
      As I said to the parent, if offline builds do not work, please file bugs. Integrating Rust code into Firefox requires the same restrictions that you're talking about, and is a use case we explicitly want to support, and already do, to a certain extent.
    - pcwalton 11y ago
      > There's a ton of things I like about Rust but the points he outlined above are things that I've seen very much impede the adoption of Rust into some environments that have similar restrictions(no download on build, build from source without binaries) for security and reproducibility reasons. They're all on the roadmap for the very near future, because Servo (and Rust-in-Gecko) needs them. There's nothing in the design of Cargo that prevents these from being solved. Personally, I love Cargo. Autoconf is miserable and I would hate to go back to it.
    - mcguire 11y ago
      Reproducibility is the thing that bothers me most about auto-downloading build systems. On the other hand, Cargo (IIRC) doesn't do what Maven does: if you say you want version X, you get version X or anything newer (unless you jump through hoops that I've never seen anyone jump through). [Security just scares the piss out of me in general; downloading binaries is probably the smallest problem.]
      - burntsushi 11y ago
        Cargo follows semver by default. Specifying version "1" means "1.x.x, <2". Pinning versions is simple. e.g., "=1.2.3". You can read more about it here: http://doc.crates.io/crates-io.html http://doc.crates.io/crates-io.html
- markus2012 11y ago
  Related: we're wondering how to use Rust because currently all non-Rust dependencies in our org are pulled from: - corporate source code control systems - corporate central repositories - caching/proxying immutable repositories These ensure all projects are built from known sources. We _know_ we can get consistent builds. When using Cargo: - Project owners update projects and don't bump the version. New bugs / security problems could be injected even though we haven't changed a thing internally. - crates.io isn't always up. - Trust: we legally can not trust (PCI compliance violations - 2015 rules (viral) ) the public crates.io repository. Besides PCI compliance, it's not possible for crates.io to guarantee perfect security (so many reasons, obviously). * I'm hoping folks who have addressed this issue (or are addressing it, or are planning on addressing it) would comment.
  - burntsushi 11y ago
    > Project owners update projects and don't bump the version. New bugs / security problems could be injected even though we haven't changed a thing internally. You can't update a crate on crates.io without bumping the version. Once a version is published, it cannot be removed. (It can be "yanked," but even yanking it does not make it completely inaccessible.) > These ensure all projects are built from known sources. We _know_ we can get consistent builds. Cargo isn't coupled to crates.io. You can run your own registry index. (Note the `[registry]` config section: http://doc.crates.io/config.html http://doc.crates.io/config.html) --- All of the code that powers crates.io is open source. On top of that, crate dependencies can be specified via git URLs or locations on disk. Repeatable builds are well supported IMO.
  - steveklabnik 11y ago
    Ahh PCI compliance :) I think Burntsushi gave a good answer here. We want these features! It's a matter of getting the requirements correct, and then helping build them. We have some of this stuff already, and are working on what Firefox needs, which is very similar, but would love for anyone who has a stake in this to help tell us about what they need, specifically. If that's you and or your org, starting a thread on http://internals.rust-lang.org/ http://internals.rust-lang.org/ would be quite helpful.
  - 11y ago
deleted 11y ago
[deleted]

by dozzie 11y ago

steveklabnik 11y ago

> It should never be the same step. This is just going to be a preference then. I much prefer not having to type two things to do what's conceptually one: please build my code. "cargo fetch" means you don't have to do the download step manually. IE, you _can_ do it in two commands if you'd like. > It means it's pretty much random for your purposes. We are just going to have to agree to disagree on this one. First of all, you _already_ need an equally 'random' binary: rustc itself. Which is also bootstrapped. Second, it's not clear to me why bootstrapping is valid for a compiler, but not for any other kind of project. Cargo is a build system, written in Rust, so it uses Rust's build system.

dozzie 11y ago
> This is just going to be a preference then. No, it is not. * It's not always that you have internet connection when building your code. * It's not always that you have access to the website code is downloaded from (websites break, and companies have different policies about internet), and even if you do, you don't always have it direct (e.g. proxy). * And at the last, people will build code for various purposes, including building packages. Building a package should be a repeatable operation and should always use only clean source (no artifacts from previous builds), and downloading random things on every build from clean source is very easy way to break the process. >> It means it's pretty much random for your purposes. > We are just going to have to agree to disagree on this one. First of all, you _already_ need an equally 'random' binary: rustc itself. No. I downloaded Rust compiler myself (or had it installed from a package). I controlled that, it didn't hit me in my face unexpectedly. > Which is also bootstrapped. s/also//. Cargo is not bootstrapped, because it needs pre-built Cargo to build itself. Compare this to Rust compiler: you start with nothing but C(++? I don't remember) compiler, and end with Rust compiler. No intermediate download involved. > Second, it's not clear to me why bootstrapping is valid for a compiler, but not for any other kind of project. Cargo is a build system, written in Rust, so it uses Rust's build system. It's not invalid, quite the contrary. It's just Cargo doesn't boostrap itself out of clean code. It's that simple. I wouldn't have as big problem with it if its build process produced an intermediate, crippled Cargo binary. I would then complain about requiring external dependencies to be downloaded (in contrast to included), but that would be difference on strategy preferences.
- vvanders 11y ago
  Going to have to agree with dozzie here, he's right on almost all accounts. There's a ton of things I like about Rust but the points he outlined above are things that I've seen very much impede the adoption of Rust into some environments that have similar restrictions(no download on build, build from source without binaries) for security and reproducibility reasons.
  - steveklabnik 11y ago
    As I said to the parent, if offline builds do not work, please file bugs. Integrating Rust code into Firefox requires the same restrictions that you're talking about, and is a use case we explicitly want to support, and already do, to a certain extent.
  - pcwalton 11y ago
    > There's a ton of things I like about Rust but the points he outlined above are things that I've seen very much impede the adoption of Rust into some environments that have similar restrictions(no download on build, build from source without binaries) for security and reproducibility reasons. They're all on the roadmap for the very near future, because Servo (and Rust-in-Gecko) needs them. There's nothing in the design of Cargo that prevents these from being solved. Personally, I love Cargo. Autoconf is miserable and I would hate to go back to it.
  - mcguire 11y ago
    Reproducibility is the thing that bothers me most about auto-downloading build systems. On the other hand, Cargo (IIRC) doesn't do what Maven does: if you say you want version X, you get version X or anything newer (unless you jump through hoops that I've never seen anyone jump through). [Security just scares the piss out of me in general; downloading binaries is probably the smallest problem.]
    - burntsushi 11y ago
      Cargo follows semver by default. Specifying version "1" means "1.x.x, <2". Pinning versions is simple. e.g., "=1.2.3". You can read more about it here: http://doc.crates.io/crates-io.html http://doc.crates.io/crates-io.html
markus2012 11y ago
Related: we're wondering how to use Rust because currently all non-Rust dependencies in our org are pulled from: - corporate source code control systems - corporate central repositories - caching/proxying immutable repositories These ensure all projects are built from known sources. We _know_ we can get consistent builds. When using Cargo: - Project owners update projects and don't bump the version. New bugs / security problems could be injected even though we haven't changed a thing internally. - crates.io isn't always up. - Trust: we legally can not trust (PCI compliance violations - 2015 rules (viral) ) the public crates.io repository. Besides PCI compliance, it's not possible for crates.io to guarantee perfect security (so many reasons, obviously). * I'm hoping folks who have addressed this issue (or are addressing it, or are planning on addressing it) would comment.
- burntsushi 11y ago
  > Project owners update projects and don't bump the version. New bugs / security problems could be injected even though we haven't changed a thing internally. You can't update a crate on crates.io without bumping the version. Once a version is published, it cannot be removed. (It can be "yanked," but even yanking it does not make it completely inaccessible.) > These ensure all projects are built from known sources. We _know_ we can get consistent builds. Cargo isn't coupled to crates.io. You can run your own registry index. (Note the `[registry]` config section: http://doc.crates.io/config.html http://doc.crates.io/config.html) --- All of the code that powers crates.io is open source. On top of that, crate dependencies can be specified via git URLs or locations on disk. Repeatable builds are well supported IMO.
- steveklabnik 11y ago
  Ahh PCI compliance :) I think Burntsushi gave a good answer here. We want these features! It's a matter of getting the requirements correct, and then helping build them. We have some of this stuff already, and are working on what Firefox needs, which is very similar, but would love for anyone who has a stake in this to help tell us about what they need, specifically. If that's you and or your org, starting a thread on http://internals.rust-lang.org/ http://internals.rust-lang.org/ would be quite helpful.
- 11y ago

deleted 11y ago

[deleted]