Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Release engineering is exhausting so here's cargo-dist

blog.axo.dev

Post reply on HN
Print view View original

51–60 of 66 posts

Re: Release engineering is exhausting so here's cargo-dist

#51

Post by detaro »

bin_bash wrote: post #48
nine_k wrote: post #41

Earlier quoted context omitted.

Github's CI is a fine way to build binaries. Github's CDN is a fine way to host binaries in a highly available manner which is also not easy to tamper with. GitHub's project page gives instant access to source code, and to a rich README. I don't see how Github in this regard is any worse than npm or pypi. What I would appreciate is a way to sign binaries the same way commits are signed, attesting that it was built fr…

with npm: $ npm install foo # or $ npx foo with github: Find repository Click latest release, downloads to ~/Downloads $ tar -xvzf ~/Downloads/some.tar.gz $ cp foo/bin/foo /usr/local/bin

As clearly laid out in the article, the rust equivalent to npm install is

    cargo install foo
The entire point of providing downloads is for people who don't have dev tools already installed.

Re: Release engineering is exhausting so here's cargo-dist

#52

Post by bin_bash »

loveparade wrote: post #49

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. 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.

Unbelievable. So if they don't use Nix they simply don't deserve to use the software?

I really wish people wouldn't get so zealous all the time about their favorite technology.

Re: Release engineering is exhausting so here's cargo-dist

#53

Post by docandrew »

Really impressive work. The description of “release engineering” really hit home in regards to the slow feedback cycle with everything CI/CD.

Also, seeing the initial attempt fail because of a missing C dependency is a common problem with a lot of language-specific package managers.

Re: Release engineering is exhausting so here's cargo-dist

#55

Post by loveparade »

bin_bash wrote: post #52
loveparade wrote: post #49

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. 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.

Unbelievable. So if they don't use Nix they simply don't deserve to use the software? I really wish people wouldn't get so zealous all the time about their favorite technology.

Nix builds binaries. You don't need nix to run binaries built using nix. Just like you don't need Cargo to run binaries built using cargo. This is about developer tooling.

Re: Release engineering is exhausting so here's cargo-dist

#56

Post by hhhhhhhhih »

howinteresting wrote: post #45
SOLAR_FIELDS wrote: post #34

Earlier quoted context omitted.

I think that this article and the discussion around it are more of a condemnation of the way GitHub Actions and similar software works rather than a generic “releasing software is hard”. One of the first things this guy mentioned in the article is that he went down this route because GHA sucks and he can’t run it locally (I know about act, but it ain’t a solution for everything) I realize you’ve probably thought abou…

Woman, she. In general, please don't unnecessarily gender (verb) people whose gender (noun) you don't know. Using "they" has been fine since the 13th century.

[flagged]

Re: Release engineering is exhausting so here's cargo-dist

#57

Post by bombolo »

chatmasta wrote: post #38
ag_dubs wrote: post #27

Earlier quoted context omitted.

we actually agree and are working on this! github releases are just an easy initial target, and makes our tool a drop-in replacement for the kinds of things people are already doing. longer-term we'd like to see something more robust, and cargo-dist is the first cog in that machine. i have personally packaged and published many rust devtools on npm (cloudflare's wrangler, apollo's rover, wasm-pack) but that was large…

> as a former npm registry engineer i'm curious what you find to be the particular value of publishing to npm I have to admit I find this to be an amusing sentence. :D Poor npm (maybe rightfully) does not have the best reputation. I suppose it appeals to me mostly for reasons of personal bias, and the thought that most people downloading binaries from GitHub probably have node installed. Although I'm probably wrong a…

> most people downloading binaries from GitHub probably have node installed

There are millions, perhaps even billions of people who aren't js developers.

I'm one of them :)

Re: Release engineering is exhausting so here's cargo-dist

#58

Post by Zababa »

jakub_g wrote: post #14
Gankra wrote: post #11

Earlier quoted context omitted.

Correction on this someone else sent me: The check of interest is for a Mark Of The Web[0] flag that Windows includes in file system metadata. The builtin unzipping utility just faithfully propagates this flag to the files it unpacks. Other utilities like 7zip are unlikely to do this propagation (effectively clearing it). But yeah either way it has nothing to do with code signing! [0]: https://nolongerset.com/mark-of…

If someone's interested with more details about MoTW, EricLaw (long time MSFT engineer at IE and Edge teams) got you covered: https://textslashplain.com/2016/04/04/downloads-and-the-mark... https://textslashplain.com/2022/12/02/mark-of-the-web-additi...

Interesting, thank you for sharing!

Re: Release engineering is exhausting so here's cargo-dist

#59

Post by nsteel »

IshKebab wrote: post #4

> 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! Yes! Why is this accepted?? 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…

If you just want to solve fundamental build issues (rather than say, uploading artefacts etc), I open a PR, make the silly small edits/experiments using the in-browser file editor, then it runs the CI each time. If I ever get it working, I then squash all the crappy debug I did to get there. Miles from ideal but a slight improvement.

Re: Release engineering is exhausting so here's cargo-dist

#60

Post by Yoric »

ZeroCool2u wrote: post #3

"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!" One of the most honest paragraphs ever…

Ouch. Python on Windows? I sympathize.
Post reply on HN