"Alright so I've given you The Pitch of how this should work, but how does it actually work today? Well, yes, I wouldn't announce this if not -- but there's a lot of future work to do! Actually no I take that back, it's definitely perfect. Those familiar with my broader oeuvre know this will absolutely be a perfectly crafted demo that avoids all the sharp corners of cargo-dist!"<p>One of the most honest paragraphs ever written.<p>Seriously though, great tool and great write up. I hope something like this lands as an official cargo feature. Coming from mostly Python land at work with crazy dependencies for TF and PyTorch GPU support (On Windows sometimes!) makes me super jealous.
I think this would benefit from an example repo that shows just Cargo.toml for a simple src/main.rs with `fn main() { println!("Hello, world!"); }` project with the simplest needed .github/workflows/foo.yaml possible to actually use this.<p>If it was in the article and I missed it I apologize.
> Congrats kid you're A Release Engineer now and your life is hell. Enjoy debugging basic typos on a remote machine with 20 minute latency because you sure can't run those Github CI bash-scripts-in-yaml files locally!<p>Yes! Why is this accepted??<p>Gitlab has a way of running CI locally (for Docker based builds anyway; who knows about Windows or Mac) but a) it doesn't support the same features at the "proper" one (even basic ones like the `default` key) and b) they deprecated it!<p>Ok in fairness they've stated in a random comment that they won't remove it before providing an alternative.... But still, how is this not a core feature of all CI systems?
> (Did you know the warning you get on Windows isn't about code signing, but is actually just a special flag Windows' builtin unzipping tool sets on all executables it extracts?)<p>My jaw hit the floor here.
I'm really not a fan of the "download the prebuilt binary from github releases" workflow that's been proliferating along with the popularity of Rust. It seems like a step backward in terms of secure package management, and it's surprising to me that Rust doesn't offer a more out-of-box experience for this, instead encouraging users to build from source. I understand the arguments for this, and I even find some of them convincing - namely, that the inverse problem of opaque intermediate binaries and object files would be much worse as it would cause a cascade of brittle builds and barely any packages would work.<p>But the fact remains that end users want to download a binary, and the common approach to this is to simply publish them to GitHub actions. Surely Cargo could offer a better option than this, while retaining the ability to build all packages from source (maybe you can only publish binaries to Cargo _in addition_ to the source files... or maybe Cargo.toml could include a link to GitHub releases, and Cargo could include a command for downloading directly from there.)<p>In the meantime, I've been considering publishing Rust binaries to npm (in addition to GitHub releases). I got the idea from esbuild, which is written in Go but distributed via npm. What do people think of this approach? Here's a recent blog post [0] describing the setup.<p>[0] <a href="https://blog.orhun.dev/packaging-rust-for-npm/" rel="nofollow">https://blog.orhun.dev/packaging-rust-for-npm/</a>
How does this tool differ from release-plz?: <a href="https://github.com/marcoIeni/release-plz">https://github.com/marcoIeni/release-plz</a>
OK, after reading through all that, I still can't tell if this can generate a Windows installer. Generating an installer is mentioned, but the examples seem to just generate a .tar file. Or maybe a .zip file. That's not what non-programmer Windows users expect.<p>Rust does a good job of generating Windows binaries cross-platform. But the tools for generating Windows installers are not yet cross-plaform. Does this project improve that situation?
Nearly all of these problems (except for maybe the Windows one) are solved by publishing a nix flake with your application and telling people to install that instead.<p>Not everyone uses nix, but I'd rather push its adoption than trying to build these kind of solutions for all possible language ecosystems when a general solution already exists and works great.
If you happen to install a lot of things with cargo, check out cargo-binstall: <a href="https://github.com/cargo-bins/cargo-binstall">https://github.com/cargo-bins/cargo-binstall</a><p>It'll fetch the binary release from the repo so you don't have to compile it yourself.
i really enjoy goreleaser <a href="https://github.com/goreleaser/goreleaser/">https://github.com/goreleaser/goreleaser/</a> and use it with rust <a href="https://github.com/chmouel/snazy/blob/main/.goreleaser.yaml#L11">https://github.com/chmouel/snazy/blob/main/.goreleaser.yaml#...</a> combined with build matrix <a href="https://github.com/chmouel/snazy/blob/main/.github/workflows/releaser.yaml#L33">https://github.com/chmouel/snazy/blob/main/.github/workflows...</a>
Awesome thank you. I'm adding it to the cargo favorites list: <a href="https://github.com/sixarm/cargo-install-favorites">https://github.com/sixarm/cargo-install-favorites</a><p>Tiny feedback:<p>- Can you consider changing "git add ." to be explicit e.g. "git add Cargo.toml .github/workflows/release.yml"?<p>- How about modifying Cargo.toml to add cargo-dist as a dev-dependency? I know it's not strictly necessary; it's just very helpful for typical collaboration.
Really impressive work. The description of “release engineering” really hit home in regards to the slow feedback cycle with everything CI/CD.<p>Also, seeing the initial attempt fail because of a missing C dependency is a common problem with a lot of language-specific package managers.