(Pre-)RFC: `river` Application Distribution

[jamesmunns]

Open Question: How do we build, release, and package river?

We will need to figure out how we make release builds of river, and how to make them available to early users. This may not necessarily be the "permanent" option - that will require collaboration with distribution packagers, etc.

For now, prebuilt binaries available on GitHub are likely reasonable for demonstration, and building from source with cargo install --locked is also reasonable.

I do also intend to investigate and likely use cargo-dist to power this initial release process.

I am open to suggestions or thoughts here, this is me generally signalling intent towards initial distribution plans.

[mcpherrinm]

A “plain” binary and a docker image would be a good set of artifacts. Both can be built and hosted on GitHub as part of making a release with a GitHub action.

[jamesmunns]

@mcpherrinm yep! cargo-dist automates and generates these workflows automatically, which is my interest in it. It also creates installer scripts (if people feel like curlbashing).

A dockerfile is a good shout too!

[highb]

Beyond the application itself, I'm sure the community will want a Helm chart, or Kustomize manifests to use once the container is created. I certainly will!

[elhackeado]

@jamesmunns to answer this question

Open Question: How do we build, release, and package river?

We need to look how the application will be run/consumed by the end user. Two of the most important ways that I can think of running an application are through:

1. Binary
2. Container Image

As long as we are able to distribute river in binary format supporting popular OS: linux, macOS(intel/apple silicon) and windows, we should be good.

These binaries can be used as building block to build & distribute container images, helm charts or k8s manifests for river at later point in time.

Now to answer your question, cargo-dist looks a good option as in its readme tag line, it says "cargo-dist distributes your binaries", and that's all we need right now. We can also keep a stretch goal of distributing a minimal alpine based container image for river along with binary.

[lperdereau]

I agree on the delivery of binaries on the Github registry and a docker image, with the aim later to propose a deployment on Kubernetes platforms.

[bengaywins]

A huge vote here for Kustomize manifests with sane defaults on a prepackaged deploy. This allows for one to then use Kustomize very easily in their necessary setup (along with all that Kustomize brings to the table). Helm charts add a ton of complexity that is hard to troubleshoot whether it is Helm doing something badly with terrible error processing (ugh been there too much) or if it's related to the manifest itself or some value in your values.yaml.

Further, Kubernetes is declarative, and so is Kustomize. Keeping within the same methodology is always a good thing imo.

[cxw620]

What about publishing official pre-built package for most-used linux distros, Debian as an example, so that users can install river with apt install river like we install nginx with apt install nginx?

[jamesmunns]

@cxw620 That's definitely the long term plan, and certainly before any 1.0 release of River.

This issue is tracking "what do we do for the first few weeks + months of working on River"?

[jamesmunns]

Initial release completed: https://github.com/memorysafety/river/releases/tag/v0.2.0, closing.