Simple Script Installer (SSI)

[DannyBen]

I wanted to share a utility script I built with Bashly that might be useful for people distributing bash tools.

This is a classic "built by bashly, for bashly" scenario... 😎

When publishing a bash CLI, we often need to provide an installation script. That script usually needs to decide:

• Where to install executables (/usr/local/bin, ~/.local/bin, etc.)
• How to install man pages
• Where to place shell completions
• How to deal with permissions (sudo vs user installs)
• OS and environment differences

I found myself re-solving these problems for every project, so I created Simple Script Installer (SSI).

SSI is a bash utility that helps developers build portable setup and uninstall scripts for their CLI tools.

It provides simple primitives for installing things like:

• executables
• man pages
• shell completions
• startup files

An installer using SSI can look something like this:

#!/usr/bin/env bash
set -euo pipefail

prepare_installer() {
  # small function that downloads ssi
  # this can be created by running `ssi bootstrap setup`
  # ... trimmed ...
}

prepare_installer

ssi install bin https://github.../rush
ssi install man https://github.../rush.1
rush completions | ssi install completion - --name rush

The idea is that SSI handles the platform decisions (paths, permissions, etc.), while your install script just describes what should be installed.

If this sounds useful, you can check it out here:

https://github.com/DannyBen/ssi

It is still early stage, but I have already converted many of my setup scripts (examples) to use this approach.

I'd love feedback, suggestions, or ideas from the Bashly community.

[bkis]

I'd have to trust in the availability and integrity of another third-party tool for my install script to work, but hey, don't I have to do the same for all dependencies and the sources I install them from anyway? So yeah, this idea sounds really neat! It takes away a huge chunk of boilerplate code I'd really rather not write (and maintain!!) myself.

The only other thing that'd make me hesitate is the fact that (1.) the runtime of this "dependency" is outside of the runtime of my application and (2.) the scripts environment (the users system) is different from the environment my application runs in (which might be created or prepared by my install script). So my ability to assess the quality and fitness of this script is very limited. This isn't a good reason not to use it, though, because if I wrote this logic myself I'd be the one to make sure it works. I'm just saying I'd give up control over quite an integral piece of logic and I'd like for such a tool to be somewhat battle-tested before I integrate it.

All in all I think this could be a perfect community project that'd profit a lot from the experience of the many people shipping things to the hundreds of different platforms all the time. I guess that for this to work best (and to keep it maintainable) it'd be quite important to have a nice and clean, fun-to-work-with modular architecture with an interface for devs from the community to integrate platform-specific logic.

[DannyBen]

Yes. All are very valid points. The auditability, integrity and trust chain take a hit with this route.

Ironically, I never use setup scripts provided by others. I always look for the manual install or review the script, and create my own install/uninstall scripts.

Furthermore - I think that the need to rely on setup scripts is a problem that needs a solution. There are some tools that help part of the issues - for example, eget for downloading release assets from GitHub, but not the other problems.

To me the ideal path would be this:

1. In the same way that users have a tool that they trust - like brew, eget, npm, and all the language-specific and os-specific package managers, there should be a tool for "installing from the source" - meaning in many cases, straight from GitHub.
2. Once such a tool exists - each tool will just need to publish a manifest stating what needs to be copied where.

So, in my ideal scenario - users would already have a tool, and they run installer github:dannyben/rush

Since I know I do not have the influence and reach to manifest this scenario, I started "peeling back" from this ideal, to the closest I can, and ssi is the result.

1. The tool is not available on the user's machine, so my setup script brings it
2. The "manifest" is in that setup script itself - not for technical reasons, but to have "fewer moving parts" for this stage.

I figured even if it only ends up as a tool I use for my own scripts - I prefer maintaining one set of rules than the multiple installation scripts I had in my repos prior to that.