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

41–50 of 66 posts

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

#41

Post by nine_k »

chatmasta wrote: post #20

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 the…

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 from a particular commit, and a particular state of dependencies, by a compiler isolated from the internet. GitHub's CI runner might sign it with some private key, while a public key to check signatures would be available from github.com.

Of course that would require some cooperation from code authors, but for important code that should be manageable.

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

#42

Post by Animats »

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.

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?

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

#43

Post by wokwokwok »

chatmasta wrote: post #20

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 the…

How is distributing binaries via cargo (automatic, can’t opt out, not possible to audit, invisible) better than explicitly downloading them from github?

Just puzzled; I think binary distributions make any supply chain issues basically impossible to solve.

Vendoring them into the tool chain instead of distributing source code you can compile yourself seems the opposite of solving the problem you’ve posed.

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

#44

Post by Animats »

Animats wrote: post #42

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

The actual project is at [1].

It looks like the closest thing you can get to an installer is an 'executable zip'.

[1] https://github.com/axodotdev/cargo-dist/

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

#45

Post by howinteresting »

SOLAR_FIELDS wrote: post #34
samsquire wrote: post #29

There's so much work to do to release software. Kind of explains why everything is a website.

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.

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

#46

Post by SOLAR_FIELDS »

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.

Thanks for helping clarify this. When you mean woman (she) are you specifically referring to the OP or to Sam Squire (who I was replying to).

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

#47

Post by howinteresting »

SOLAR_FIELDS wrote: post #46
howinteresting wrote: post #45

Earlier quoted context omitted.

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.

Thanks for helping clarify this. When you mean woman (she) are you specifically referring to the OP or to Sam Squire (who I was replying to).

Talking about the author of the article, Gankra.

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

#48

Post by bin_bash »

nine_k wrote: post #41
chatmasta wrote: post #20

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 the…

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

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

#49

Post by loveparade »

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.

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

#50

Post by [deleted] »

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.

[deleted]
Post reply on HN