cargo-release VS Cargo

Between workspace inheritance and tools like cargo-release, this has become trivial for me. If people don't want to use a third-party tool, we can always be working on improving cargo further, like publishing more than one crate at a time or merging support for modifying versions.

> That’s because, while cargo is great at building things, it is very simplistic at installing them. Cargo wants everything in a few neat binaries, and that isn’t our use case. Fish has about 1200 .fish scripts (961 completions, 217 associated functions), as well as about 130 pages of documentation (as html and man pages), and the web-config tool and the man page generator (both written in python).

Our issue for this is https://github.com/rust-lang/cargo/issues/2729

Personally, I lean away from Cargo expanding into these use cases and prefer another tool being implemented on top. I've written more about this at https://epage.github.io/blog/2023/08/are-we-gui-build-yet/

Is an explicit, safe and less error prone way of doing it.

...and one that doesn't walk us down the road of (see the linked thread) the obvious desire people are going to have sooner or later to cache binary builds instead of building locally, and turn `cargo install` into some kind of binary application distribution application or app store.

If you don't believe me, read that thread, and the linked thread.

[1] - https://github.com/rust-lang/cargo/issues/13994#issuecomment...

Just look at the proposal to add an --only-dependencies flag to cargo-build.

https://github.com/rust-lang/cargo/issues/2644

Its a clusterfuck of people misdirecting the discussion, the maintainers completely missing the point, and in the end its still not even been allowed to start.

The more I've been doing open source maintenance and contributions where there isn't as much context between the code author and reviewer, the more I've been pushing for a little more than this.

- Add tests in a commit *before* the fix. They should pass, showing the behavior before your change. Then, the commit with your change will update the tests. The diff between these commits represents the change in behavior. This helps the author test their tests (I've written tests thinking they covered the relevant case but didn't), the reviewer to more precisely see the change in behavior and comment on it, and the wider community to understand what the PR description is about.

- Where reasonable, find ways to split code changes out of feature / fix commits into refactor commits. Reading a diff top-down doesn't tell you anything; you need to jump around a lot to see how the parts interact. By splitting it up, you can more quickly understand each piece and the series of commits tells a story of how the feature of fix came to be.

- Commits are atomic while PRs tell a story, as long as it doesn't get too big. Refactor are usually leading towards a goal and having them tied together with that goal helps to provide the context to understand it all. However, this has to be balanced with the fact that larger reviews mean more things are missed on each pass and its different things on each pass, causing a lot of "20 rounds of feedback in and I just noticed this major problem".

As an example of these is a recent PR of mine against Cargo: https://github.com/rust-lang/cargo/pull/14239

In particular, the refactors leading up to the final change made it so the actual fix was a one line change. It also linked out to the prior refactors that I split out into separate PRs to keep this one smaller.

Installing Trunk happens through Cargo. Remember, Cargo is more than a package manager, it also supports sub-commands.

Dependency Management in Other Languages: We've discussed Python and Node.js in this article, but dependency management is a universal concept in programming. Exploring how you handle dependencies in other languages like Java, C#, or Rust could be beneficial. (I think Rust's cargo is an excellent example of a package manager.)

Nice hack! Would it have been possible back then to use cargo to pull in some dependencies?

The clean solution of cargo script is here: https://github.com/rust-lang/cargo/issues/12207