2 ms·

Cargo is a development and build tool, and it's quite possibly the best I've ever used. I don't know of any specific reason it's "fuck the package manager". Ca

Cargo is a development and build tool, and it's quite possibly the best I've ever used. I don't know of any specific reason it's "fuck the package manager". Cargo does it's own dependency management, so I assume you mean to say that because of this, it makes it difficult to integrate into standard methods package managers use. After reading some of the email threads with OpenBSD, I do get the sense that it's complex in that situation, but isn't that because of Ports? And Ports' expectations? Most things in Ports are C, right? I haven't worked with Ports in a long time, so I don't know it very well. If you're pre-building something and pushing a package for say dpkg or rpm, I don't see a problem. If you're packaging source, then you'll need have the rust tools installed on the host to do that, which seems obvious. After that, I can see some debate about blessing versions of crates in the Rust ecosystem for use in the OS' package manager, but this starts to blur the lines between what the OS is guaranteeing and what is the responsibility of the build tool. Should an OS want to bless crates, cargo does have an override for crates.io: http://doc.crates.io/config.html http://doc.crates.io/config.html see the 'registry' section. I believe the other options in that configuration would also be things that the package manager on the OS would want to specify as well. I haven't done any of this myself, but would be interested in trying to help figure it out if you have specific concerns.

pjmlp 9y ago
My main pet peeve with cargo is lack of support for binary crates. Compiling the whole world, including dependencies is big waste of time. I already tried to play around with workspaces to see if at least crates only get compiled once. With other AOT compiled languages I use, zero third party dependencies are compiled from scratch.
- bluejekyll 9y ago
  Yeah, I agree with this. This confused me when I first started using the language. I do think there could be some better options for caching or downloading precompiled packages, but I also think this has partly helped with the development effort in Rust as well. That being said, a system wide cached package repo could work, but it also has issues (looking at you Maven) so it would be interesting to figure out how to get it "right" when dealing with source packages. This old issue discusses a bunch of this: https://github.com/rust-lang/cargo/issues/610 https://github.com/rust-lang/cargo/issues/610 I couldn't find another in a brief search. Edit: I should add that it does harken back a bit to my Gentoo days, where recompiling the world for that 10-15% architecture boost was a lot of fun, but also a waste of time in general ;)
flukus 9y ago
> Cargo does it's own dependency management Exactly, that's why it's a "fuck the package manager" approach, it ignores the package manager. > If you're pre-building something and pushing a package for say dpkg or rpm The problem is multi copies of the same dependencies everywhere adding all sorts of bloat and security issues. Not to mention introducing it's own incompatibilities. > Should an OS want to bless crates, cargo does have an override for crates.io That's a recipe for dll hell if I've ever heard one.
- bluejekyll 9y ago
  > The problem is multi copies of the same dependencies everywhere most binaries would be statically linked and compiled, so there wouldn't be copies, but you do have a valid point of an issue with needing to upgrade an tool that was build with a static dependency that has an issue. If I understand you, you're saying Rust, a general purpose language, with it's own build tool should do what exactly? I see that you believe it's doing it wrong, but every package manager for every OS out there does things differently, Rust can not fix this. > That's a recipe for dll hell if I've ever heard one. The package managers can be configured to work with Rust, and likewise Cargo can be configured to work with the various package managers, but it takes work. I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there, with the cargo manifest used to generate the various package managers dependency graphs as necessary. This would probably look a lot like, or actually be an integration with, FPM.
  - flukus 9y ago
    > but every package manager for every OS out there does things differently, Rust can not fix this. Exactly, it can't fix it but it tries to cover over this fact by bundling dependencies with every app. > I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there Basically, but more to the point, when a bug or security issue is fixed I don't want to rely on individual programs updating their dependencies. Let's say 10 years from now the rust version of gstreamer is widely used and a security issue is discovered, I want to be able to "apt-get upgrade" and know that it's patched. This is how things work now with the c version, but this can't be done with cargo, every app using the library has to update it's dependencies and many (particularly any corporate ones) will never update. Rust might be a boon for security but cargo could undermine the effort. Aside from that, static linking creates a tonne of bloat, memory and disk. There is a reason windows apps are often so bloated compared to their linux counterparts. > The package managers can be configured to work with Rust, and likewise Cargo can be configured to work with the various package managers, but it takes work. I don't think that's good enough, if rust wants to be a systems language then it has to work with the system, not be a layer on top of it like java/.net/node. It can do this technically, but culturally it's looking more like node and less like c.

pjmlp 9y ago

My main pet peeve with cargo is lack of support for binary crates. Compiling the whole world, including dependencies is big waste of time. I already tried to play around with workspaces to see if at least crates only get compiled once. With other AOT compiled languages I use, zero third party dependencies are compiled from scratch.

bluejekyll 9y ago
Yeah, I agree with this. This confused me when I first started using the language. I do think there could be some better options for caching or downloading precompiled packages, but I also think this has partly helped with the development effort in Rust as well. That being said, a system wide cached package repo could work, but it also has issues (looking at you Maven) so it would be interesting to figure out how to get it "right" when dealing with source packages. This old issue discusses a bunch of this: https://github.com/rust-lang/cargo/issues/610 https://github.com/rust-lang/cargo/issues/610 I couldn't find another in a brief search. Edit: I should add that it does harken back a bit to my Gentoo days, where recompiling the world for that 10-15% architecture boost was a lot of fun, but also a waste of time in general ;)

flukus 9y ago

> Cargo does it's own dependency management Exactly, that's why it's a "fuck the package manager" approach, it ignores the package manager. > If you're pre-building something and pushing a package for say dpkg or rpm The problem is multi copies of the same dependencies everywhere adding all sorts of bloat and security issues. Not to mention introducing it's own incompatibilities. > Should an OS want to bless crates, cargo does have an override for crates.io That's a recipe for dll hell if I've ever heard one.

bluejekyll 9y ago
> The problem is multi copies of the same dependencies everywhere most binaries would be statically linked and compiled, so there wouldn't be copies, but you do have a valid point of an issue with needing to upgrade an tool that was build with a static dependency that has an issue. If I understand you, you're saying Rust, a general purpose language, with it's own build tool should do what exactly? I see that you believe it's doing it wrong, but every package manager for every OS out there does things differently, Rust can not fix this. > That's a recipe for dll hell if I've ever heard one. The package managers can be configured to work with Rust, and likewise Cargo can be configured to work with the various package managers, but it takes work. I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there, with the cargo manifest used to generate the various package managers dependency graphs as necessary. This would probably look a lot like, or actually be an integration with, FPM.
- flukus 9y ago
  > but every package manager for every OS out there does things differently, Rust can not fix this. Exactly, it can't fix it but it tries to cover over this fact by bundling dependencies with every app. > I think what you want is every crate on crates.io to be packaged as an installable rlib and dylib for every package manager out there Basically, but more to the point, when a bug or security issue is fixed I don't want to rely on individual programs updating their dependencies. Let's say 10 years from now the rust version of gstreamer is widely used and a security issue is discovered, I want to be able to "apt-get upgrade" and know that it's patched. This is how things work now with the c version, but this can't be done with cargo, every app using the library has to update it's dependencies and many (particularly any corporate ones) will never update. Rust might be a boon for security but cargo could undermine the effort. Aside from that, static linking creates a tonne of bloat, memory and disk. There is a reason windows apps are often so bloated compared to their linux counterparts. > The package managers can be configured to work with Rust, and likewise Cargo can be configured to work with the various package managers, but it takes work. I don't think that's good enough, if rust wants to be a systems language then it has to work with the system, not be a layer on top of it like java/.net/node. It can do this technically, but culturally it's looking more like node and less like c.