4 ms·

> Specifically, system package managers are about providing a unified set of packages to end-users. Language package managers are for developers to build applic

> Specifically, system package managers are about providing a unified set of packages to end-users. Language package managers are for developers to build applications. One thing that might help people see this distinction better is if Cargo offered better post-build hooks to allow community-driven add-ons that handle packaging for the various system package managers. If a Rust developer could run cargo dist-package (or whatever it's called) and have it build a deb/rpm/pkg/msi, it'd be really easy to use cargo for the development phase and the other package managers for the distribution phase. As it is, if I want to run someone else's Rust software, I'm basically using cargo install to pull from crates and build locally.

steveklabnik 9y ago
You don't need hooks to do that today; name an executable `cargo-dist-package`, put it in your $PATH, and `cargo dist-package` Just Works. Well, you still have to implement it, but the workflow is there. Have it invoke `cargo build` and you're good to go. We've been wary to add more hooks because then you can start to emulate a system package manager with them.
- curun1r 9y ago
  It's not just triggers, though having the post-build equivalent of build.rs would be a nice feature that doesn't really change the nature of cargo in any way. It would be quite useful for doing post-build logic...for example, when building a Neon module for Node, the dylib is that cargo compiles doesn't have the .node extension that Node wants it to have. It'd be a lot simpler (and more portable) to just put that rename into a post-build.rs rather than having to do it after every build or, as I do now, using a justfile to run both commands. But 'hooks' also means making cargo more extensible. IIRC, cargo will error out if it finds a key in Cargo.toml that it doesn't recognize. It would be nice to be able to store configurations for extensions to the cargo build lifecycle in that file as well. Cargo could just ignore them. Also, it'd be nice to have a crate to read and safely write from/to Cargo.toml to make it easy for extension executables like you mentioned to use information about the build. Just being able to pass through to an executable in $PATH isn't really enabling much and, aside from that, cargo seems pretty hostile towards implementing features that the team doesn't believe in. I guess what I'm advocating for is providing generic extension points in Cargo and then sitting back to watch what the community comes up with. My experience with the Rust community is that there are a lot of exceptionally smart developers who love the language and the tooling and I think we'd get a lot of exciting and creative features if the main team were removed from the critical path. A more organic approach to evolving the way we build Rust code might come up with something better and can serve as free user research for what should be included in the official cargo tool and become the officially-recommended best practice.
  - steveklabnik 9y ago
    I hear you. I'm of two minds about this.

steveklabnik 9y ago

You don't need hooks to do that today; name an executable `cargo-dist-package`, put it in your $PATH, and `cargo dist-package` Just Works. Well, you still have to implement it, but the workflow is there. Have it invoke `cargo build` and you're good to go. We've been wary to add more hooks because then you can start to emulate a system package manager with them.

curun1r 9y ago
It's not just triggers, though having the post-build equivalent of build.rs would be a nice feature that doesn't really change the nature of cargo in any way. It would be quite useful for doing post-build logic...for example, when building a Neon module for Node, the dylib is that cargo compiles doesn't have the .node extension that Node wants it to have. It'd be a lot simpler (and more portable) to just put that rename into a post-build.rs rather than having to do it after every build or, as I do now, using a justfile to run both commands. But 'hooks' also means making cargo more extensible. IIRC, cargo will error out if it finds a key in Cargo.toml that it doesn't recognize. It would be nice to be able to store configurations for extensions to the cargo build lifecycle in that file as well. Cargo could just ignore them. Also, it'd be nice to have a crate to read and safely write from/to Cargo.toml to make it easy for extension executables like you mentioned to use information about the build. Just being able to pass through to an executable in $PATH isn't really enabling much and, aside from that, cargo seems pretty hostile towards implementing features that the team doesn't believe in. I guess what I'm advocating for is providing generic extension points in Cargo and then sitting back to watch what the community comes up with. My experience with the Rust community is that there are a lot of exceptionally smart developers who love the language and the tooling and I think we'd get a lot of exciting and creative features if the main team were removed from the critical path. A more organic approach to evolving the way we build Rust code might come up with something better and can serve as free user research for what should be included in the official cargo tool and become the officially-recommended best practice.
- steveklabnik 9y ago
  I hear you. I'm of two minds about this.