search

radicle-dev / radicle-cli

Radicle CLI
https://app.radicle.network/alt-clients.radicle.eth/radicle-cli
GNU General Public License v3.0
87 stars 22 forks source link

radup Design #227

Open pinkforest opened 2 years ago

pinkforest commented 2 years ago

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:

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:

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

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 commented 2 years ago

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 commented 2 years ago

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 :shrug:

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 commented 2 years ago

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 commented 2 years ago

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!