Rollkit CLI Binary Distribution

[MSevey]

Goal

Make the rollkit CLI binary easily accessible cross platform.

Why

We are leaning into the rollkit CLI from a DevX standpoint. We are rebuilding the rollkit docs around it to make the quick start and tutorials easier and better.

Making the binary as easy to access cross platform is a key enabler to this.

Assumptions

The key assumptions to be aligned on are centered around the potential rollkit user that is visiting the rollkit docs.

For initial product market fit (PMF), rollkit is targeting and prioritizing cosmos devs. This assumes some familiarity with the cosmos-sdk and ecosystem.

As such, it is reasonable to assume and expect that the developers interested in rollkit have golang installed.

Distribution Methods

The current methods of distributing binaries can be categorized as follows:

• Building from Source
• OS specific distribution
• Alternate distribution registries

Building from Source

For the purposes of this discussion, building from source includes both building the binary from the source code and downloading a pre-built binary from the github release.

Building from the source code requires golang to be installed by the user. However we've already stated why this is a reasonable assumption. Using golang's installation code, the binary can be reliably installed in the user's execution path.

Downloading the binary from the github release requires the team to have the binaries built via CI (or manually) for each release and doesn't require golang to be installed initially. Since the user is downloading the binary directly, they would need to make sure the binary is put in their execution path.

OS Specific Distribution

OS specific distributions (homebrew, apt, choco, etc) allow users to download the rollkit binary directly with an assumed familiarity of other binary installations. These methods would also place the binaries in the user's execution path. The main drawback to these methods is that they add maintenance overhead to the team.

Alternate Distribution Registries

Alternate distribution registries, such as distributing the binary via npm, have a similar situation as the OS specific distributions but with the added assumption that the user is set up to use the distribution registry. In the example of npm, we are replacing the assumption of the user having golang installed with the assumption that they have npm installed.

Other Considerations

Another consideration when thinking about distribution methods is the balance of ease of access and team maintenance burden. Having the binary accessible in as many places as possible, such that users can choose to install it via the method they are most comfortable with is great DevX. However, with each new distribution method, there is an added level of maintenance that the team must maintain ongoing.

Recommendations

Based on the above, it is my recommendation to stick with building from source as the primary method of installation. This recommendation is based on:

1. The assumption that rollkit is targeting cosmos developers, therefore it is reasonable to expect they have golang installed
2. Keep the maintenance burden of the team as low as possible
3. Let the golang installation code handle the cross platform support

As a secondary method of installation, I would recommend that goreleaser is used for building the binaries as part of the release. This would be useful for:

1. Having a second method of installation that doesn't require golang being installed
2. Having a pre-built binary enables an easy first level of debugging if a user has issues with building from source.

[MSevey]

Resolved and aligned offline.