Open pinkforest opened 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.
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.
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.
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!
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
Filesystem - Paths (Global)
Global is always used in $PATH or %PATH% if User Local is not present (priority wise)
radup - Usage
$ radup --help
radup show