radup Design

[pinkforest]

Problem Statement

Modern users today expect single-step curl -type install experience and are well adjusted to curl rustup, foundryup etc.

In addition it should all work:

• Regardless of the target triplet / distro esoterics (Besides *NIX/POSIX-Like | Windows-like difference)
• To help keep the tooling updated
• To enforce at-source signatories & auditable binary
• Install tooling from release channels, PRs, branch/hash to accelerate contributor experience

Currently our install is multi-step process and prone to failure including system dependencies leading to high user friction.

Binaries install is also tightly coupled to packaging systems when it is not really required and there are symbolic ref's to system libraries that don't exist (e.g. OpenSSL) when typically this is vendored to avoid confusion.

The binaries install is also highly platform dependant coupled with GCP when we can simply run this artefacting simply via CI upon PR, push-on-branch and release reducing our centralised platforms footprint we rely on.

Get-Started

get-started should detect the browser platform and offer installation method either as:

• *NIX/POSIX -Like
• Windows -Like

The above yields installed binary radup and stable (default) rad binary

radup will not have any dependency on the distro / system packaging manager.

Target Platforms

These will be built (CI native gets also tested) upon push on main in CI and then stuffed into release artefacts

• linux x86_64 glibc
• linux x86_64 musl - Think small containers
• linux armv6 (ARM11) - Raspberry Pi
• macos aarch64 - Mac M1
• macos x86_64 - Max Intel's
• windows x86_64 (apparently there is now Surface Pro X w/ ARM chip)

Binaries are stuffed with cargo-auditable and signed at source.

Minimal symbolic linking and statically vendored deps if any.

Install - *NIX/POSIX -Like

curl https://up.radicle.xyz | sh

Also distribute radup-init to distro's packaging

Install - Windows -Like

hmm.

Filesystem - Paths (User Local)

User local $PATH/bin is always placed first

Directory (Default)	Description
~/.rad	Radicle user directory
~/.rad/bin	Radicle installed binaries

Files	Description
~/.rad/bin/rad	Symlink to the current default rad
~/.rad/bin/rads/stable	Symlink to the current stable rad
~/.rad/bin/rads/nightly	Symlink to the current nightly rad
~/.rad/bin/rads/vX.Y.Z	Rad X.Y.Z binary

Filesystem - Paths (Global)

Global is always used in $PATH or %PATH% if User Local is not present (priority wise)

Directory (Default)	Description
/usr/local/bin	Radicle installed binaries (*NIX/POSIX -Like)
%PROGRAM_FILES%	Radicle installed binaries (Windows -Like

radup - Usage

$ radup --help

radup 0.1.0 (beefbeef 2022-07-12)
The Radicle installer

USAGE:
    radup [FLAGS] <SUBCOMMAND>

FLAGS:
    -v, --verbose    Enable verbose output
    -q, --quiet      Disable progress output
    -h, --help       Prints help information
    -V, --version    Prints version information

SUBCOMMANDS:
    show           Show the active and installed rads
    update         Update all installed binaries by channels
    check          Check for and report on any updates
    default        Set the default rad [ channel | version | pr x | commit branch/hash ]
    doc            Open the documentation for the current default rad

radup show

$ radup show
Host: x86_64-unknown-linux-gnu
radup home:  /home/radicle/.rad

installed rads
--------------------

version-0.2.0
pr-18422-20220722-beefdead
commit-beefdead
nightly-20220824-000 *default

[adaszko]

So the biggest issue that I see with this proposal is we seem to be comparing
ourselves to a compiler. What I think we should be comparing ourselves to
instead is any other version control system: git, hg, etc.

For instance, as you can still read in the original blogpost, the reason
rustup was brought to life, was to make it easier to do cross-compilation,
something that is very unique to a compiler in terms of packaging, and
generally not supported by standard package managers. Cross-compilation is
not something that a version control system needs to do. I think we should ask
ourselves why the authors of e.g. git didn't feel the need for a gitup
tool.

There are some inaccuracies in the GitHub issue:

Currently our install is multi-step process and prone to failure including
system dependencies leading to high user friction.

There are no system dependencies in the current installation process besides
standard system tools that come pre-installed with the OS for the most part (if
not all). The binaries are statically linked and they don't depend on any
shared libraries installed on the system. If you're referring to building from
source here, that's not something radup will solve either.

Another point is that nobody seems to care about the uninstallation process
with the curl | sh style installs. I'd say that is what users expect to be
easy too.

To help keep the tooling updated

This is totally achievable with the system-specific package managers. That's
how people have been doing things for decades at this point. What *up tools
do in this case, is to introduce an exception to the rule of how to update
software. Let's please not assume that Radicle is the center of the user's
world. It's just a yet another tool in the user's toolbox.

Binaries install is also tightly coupled to packaging systems when it is not
really required and there are symbolic ref's to system libraries that don't
exist (e.g. OpenSSL) when typically this is vendored to avoid confusion.

I think you're confusing installing Radicle by building from source with
installing by downloading binaries via the package manager. The problems
you're mentioning pertain only to installing from source. There aren't any
symlinks or OpenSSL if you're installing via the package manager.

The binaries install is also highly platform dependant coupled with GCP when
we can simply run this artefacting simply via CI upon PR, push-on-branch and
release reducing our centralised platforms footprint we rely on.

There is nothing platform-dependent or centralized about our current setup.
Every part of it is replaceable. The APT repository we do host on GCP can be
replaced at any point with a bog-standard HTTP server. We use the GCP service
purely to save ourselves the inevitable maintenance burden. The same burden
that will be incurred onradup too.

radup will not have any dependency on the distro / system packaging manager.

What's the plan for installing on NixOS?

And, last, but not least, the paths proposed under the "Filesystem - Paths
(User Local)" section do not conform to XDG Directory Specification. I think
we should conform to reasonable standards where there are some.

To wrap things up, I suggest you go through the installation process again, but
using binaries from the package manager, not building from source, as I feel
the frustration with the installation process grew out of inadvertently mixing
the two.

[cloudhead]

I'm not going to comment specifically on radup, but I'll say this: until installation on all major platforms is a single command, it's not good enough.

We can get to that point in two ways I think:
(1) All major OSes ship rad in their package manager
(2) We use curl/wget as our package manager

As an ArchLinux user, I currently don't have an easy way of installing radicle. The debian installation process is multiple commands (which for apt maxis I'm sure is not a problem). The brew one is the best so far, though it's still not as easy as brew install radicle.

Though my ideal would be pacman -S radicle, we don't have that right now and the next best thing is curl https://up.radicle.xyz | sh 🤷

Package managers made it really hard to decentralize package curation, so here we are. And before anyone brings up the AUR, that is a worse-of-all-worlds option, except as Adam pointed out, that it comes with a standard uninstallation process.

[adaszko]

The brew one is the best so far, though it's still not as easy as brew install radicle.

Technically, this is just a matter of submitting a PR to the main Homebrew repo. Now, whether they accept it or consider a project-specific brew tap enough of a solution, is a separate issue.

And before anyone brings up the AUR

I'll be happy to create an AUR package until something better comes along (maybe radup). I remember the process to be rather simple.

[adaszko]

I'll be happy to create an AUR package until something better comes along (maybe radup). I remember the process to be rather simple.

User @TripleSpeeder just beat me to it 🎉 . Thanks!