5 ms·

I hope that never ever happens. We don't need a C-like mess where every library has a bespoke build process that doesn't work across OSes.

proto_lambda 5y ago
OP seems to be conflating the concepts of cargo (the rust build system with dependency management functionality) and crates.io (the main and default package repository today). It is totally possible to use cargo without ever touching crates.io, but if you need any dependencies you'll of course have to provide them through some other means (local file system, git repositories, or a custom package repository).
- mort96 5y ago
  Cargo defaults to downloading stuff from crates.io. I certainly wish cargo was just a build system which doesn't care where you get your packages from, but that's not what it is.
  - steveklabnik 5y ago
    Cargo does not care where you get your packages from, but it does have a default place. If you don't like it, it is easy to change.
    - mort96 5y ago
      That... is caring where I get packages from. Something like make or cmake doesn't care at all how packages end up on my drive. Almost everyone uses cargo in a way which makes cargo automatically download them from the web.
      - steveklabnik 5y ago
        If you're making that argument, you could easily turn it around: make or cmake do care where your pacakges are; they by default only build things on your local drive. The point is: all options are available for all systems, so suggesting any workflow doesn't work with any of these is just incorrect.
        mort96 5y ago
        My point is that building code coming from my local drive is much less problematic than automatically downloading the code from some random website. And I never said any workflow doesn't work with Cargo. I said I wished it didn't download code (by default) and that it didn't care how code ended up on my drive, that it just worked like a normal build system. That you can use Cargo in that way doesn't help.
        saghm 5y ago
        > My point is that building code coming from my local drive is much less problematic than automatically downloading the code from some random website. How does the code get on your hard drive? I'd imagine from downloading it from some random website (arguably _more_ random since it's less likely to be a centralized place like crates.io). Or you could vendor the dependencies so that they're included when you get the source code for the thing you're working on, but as mentioned throughout this discussion, cargo lets you do that too.
- estebank 5y ago
  I could totally see the Linux Kernel setting up their own alternative Rust package mirror that cargo uses: you get the ease of use of cargo while also getting the desired level of curation. It could either be treated as owned packages, only projects written by kernel contributors, or it could be the linux distro packager model, where blessed crates at a point in time are curated, but not necessarily audited beyond some smoke tests.
enriquto 5y ago
> where every library has a bespoke build process doesn't work across OSes cargo sounds pretty much like a new bespoke build process that doesn't even work across different languages on the same OS
- sanderjd 5y ago
  Yes. It turns out this works much better than the situation previously. The bespoke-per language model turns out to have fewer drawbacks than the bespoke-per-library-and-OS model. Note: fewer drawbacks, not none. I would not have predicted this a priori, for what it's worth, and I was very critical of and first one of these I became familiar with (rvm), but it turns out to work well in practice. I still think cross-language efforts (like bazel and I'm sure there are others, maybe nix?) seem generally better, but I suspect there is some fairly good reason they are less widely used.
  - howinteresting 5y ago
    The problem with bazel and nix is that they are totalizing build systems. They want everything to bend to their worldview, and ask for an all-in commitment. Cargo etc require somewhat less of a commitment.
    - sanderjd 5y ago
      Right, but it seems like it would probably make more sense to pick a totalizing system, if you know you'll have a polyglot environment, which seems pretty inevitable for any business (as opposed to just like a side project). But I think there are probably good reasons this isn't the most common way to do things, and I just don't know them.
      - howinteresting 5y ago
        Many businesses do pick totalizing systems -- many medium-size or above corporations use bazel, and a few use nix. There's also some tooling to convert Cargo.toml to bazel and nix build files, though I don't know how well that works. I think the problem is that bazel and nix are just not that easy to get started with. If you're using them you're likely to have a team (or at least one person) working full-time on them, since bending everything to a singular worldview involves a lot of work.

proto_lambda 5y ago

OP seems to be conflating the concepts of cargo (the rust build system with dependency management functionality) and crates.io (the main and default package repository today). It is totally possible to use cargo without ever touching crates.io, but if you need any dependencies you'll of course have to provide them through some other means (local file system, git repositories, or a custom package repository).

mort96 5y ago
Cargo defaults to downloading stuff from crates.io. I certainly wish cargo was just a build system which doesn't care where you get your packages from, but that's not what it is.
- steveklabnik 5y ago
  Cargo does not care where you get your packages from, but it does have a default place. If you don't like it, it is easy to change.
  - mort96 5y ago
    That... is caring where I get packages from. Something like make or cmake doesn't care at all how packages end up on my drive. Almost everyone uses cargo in a way which makes cargo automatically download them from the web.
    - steveklabnik 5y ago
      If you're making that argument, you could easily turn it around: make or cmake do care where your pacakges are; they by default only build things on your local drive. The point is: all options are available for all systems, so suggesting any workflow doesn't work with any of these is just incorrect.
      - mort96 5y ago
        My point is that building code coming from my local drive is much less problematic than automatically downloading the code from some random website. And I never said any workflow doesn't work with Cargo. I said I wished it didn't download code (by default) and that it didn't care how code ended up on my drive, that it just worked like a normal build system. That you can use Cargo in that way doesn't help.
        saghm 5y ago
        > My point is that building code coming from my local drive is much less problematic than automatically downloading the code from some random website. How does the code get on your hard drive? I'd imagine from downloading it from some random website (arguably _more_ random since it's less likely to be a centralized place like crates.io). Or you could vendor the dependencies so that they're included when you get the source code for the thing you're working on, but as mentioned throughout this discussion, cargo lets you do that too.
estebank 5y ago
I could totally see the Linux Kernel setting up their own alternative Rust package mirror that cargo uses: you get the ease of use of cargo while also getting the desired level of curation. It could either be treated as owned packages, only projects written by kernel contributors, or it could be the linux distro packager model, where blessed crates at a point in time are curated, but not necessarily audited beyond some smoke tests.

enriquto 5y ago

> where every library has a bespoke build process doesn't work across OSes cargo sounds pretty much like a new bespoke build process that doesn't even work across different languages on the same OS

sanderjd 5y ago
Yes. It turns out this works much better than the situation previously. The bespoke-per language model turns out to have fewer drawbacks than the bespoke-per-library-and-OS model. Note: fewer drawbacks, not none. I would not have predicted this a priori, for what it's worth, and I was very critical of and first one of these I became familiar with (rvm), but it turns out to work well in practice. I still think cross-language efforts (like bazel and I'm sure there are others, maybe nix?) seem generally better, but I suspect there is some fairly good reason they are less widely used.
- howinteresting 5y ago
  The problem with bazel and nix is that they are totalizing build systems. They want everything to bend to their worldview, and ask for an all-in commitment. Cargo etc require somewhat less of a commitment.
  - sanderjd 5y ago
    Right, but it seems like it would probably make more sense to pick a totalizing system, if you know you'll have a polyglot environment, which seems pretty inevitable for any business (as opposed to just like a side project). But I think there are probably good reasons this isn't the most common way to do things, and I just don't know them.
    - howinteresting 5y ago
      Many businesses do pick totalizing systems -- many medium-size or above corporations use bazel, and a few use nix. There's also some tooling to convert Cargo.toml to bazel and nix build files, though I don't know how well that works. I think the problem is that bazel and nix are just not that easy to get started with. If you're using them you're likely to have a team (or at least one person) working full-time on them, since bending everything to a singular worldview involves a lot of work.