A framework to manage programs from web sources for non-privileged users on Linux systems
During occasional strolls on reddit or github, my attention is often drawn towards programs that increase productivity or provide an enhancement over others. (As a somewhat irrelevant side note - these programs mostly work in the command line.) Usually these programs are available for download as binary or script, meaning that naturally, the management (installation, upgrade, removal) of those programs has to be performed manually. At this point sdd
comes into play: It provides a framework to automatize the tasks of managing the programs (or, in sdd
terminology, 'apps'). The procedures to manage specific apps are defined within scripts in this repository (at lib/sdd/apps/user/
).
sdd
enables me to keep track of my favorite programs, on different machines. I'm working towards having systems set up in a reproducible way on my machines. sdd
helps me, since I might have different Linux distributions installed on these machine, with different package manager providing different versions of required programs (or none at all). I can freeze the versions of all apps managed by sdd with sdd list --installed > sdd_freeze.txt
, and re-create them with sdd install <(cat sdd_freeze.txt | xargs)
.
Finally on some systems I might not have root access, and hence I can't install missing programs using a package manager. sdd
allows for unprivileged management of programs.
sdd
is a simple collection of bash scripts, not a mature package manager (neither do I aim to turn it into one...). Using it might break things on your system (e.g. overwrite existing program files).
When using sdd
, you execute functionality to manipulate your system. Especially, you download programs from third parties, and install them on your system. Most sources are provided by GitHub releases pages. Keep in mind that repositories can be compromised, and malicious code placed inside; and sdd
will still happily download it. (If you have an idea how to mitigate this security flaw, please open an issue.)
sdd
is targeted to 64bit Linux systems. Some apps might not work when installed to different architectures. If available, bash
and/or zsh
shell completion and man
pages are set up when installing an app.
The following screencast demonstrates how sdd
is used to install, upgrade and uninstalled the fd
utility.
Clone the directory and run the bootstrap script to install sdd
to ~/.local
:
git clone https://github.com/pylipp/sdd
cd sdd
git checkout v0.1.1.0 # or any other revision
./bootstrap.sh
You can specify the installation directory with the PREFIX
environment variable:
PREFIX=/usr ./bootstrap.sh
Please verify that the bin
sub-directory of the installation directory is present in your PATH
. You might want to append this to your shell configuration file:
export PATH="~/.local/bin:$PATH"
Same applies for the MANPATH
:
export MANPATH="~/.local/share/man:$MANPATH"
For enabling zsh
completion functions (oh-my-zsh
users: put this before the line that sources oh-my-zsh.sh
since it calls compinit
for setting up completions):
fpath=(~/.local/share/zsh/site-functions $fpath)
For enabling bash
completion functions, you should be fine if you already use the bash-completion
package. Otherwise add this snippet to your ~/.bashrc
:
if [ -d ~/.local/share/bash_completion ]; then
# Source custom completion files
while IFS= read -r -d '' f; do
. "$f"
done < <(find ~/.local/share/bash_completion -type f -print0)
fi
sdd
is tested with bash
4.4.12.
sdd
depends on bash
, git
, and wget
. Python-related apps require python3
.
Once the program is bootstrapped, upgrade to the latest version by
sdd upgrade sdd
Install an app to SDD_INSTALL_PREFIX
(defaults to ~/.local
) with
sdd install <app>
You can specify a custom installation prefix like this:
SDD_INSTALL_PREFIX=~/bin sdd install <app>
or by exporting the SDD_INSTALL_PREFIX
environment variable.
By default, sdd
installs the latest version of the app available. You can specify a version for installation:
sdd install <app>=<version>
This command overwrites an existing installation of the app without additional conformation.
The format of the
<version>
specifier depends on the app that is managed (usually it's the tag of the release on GitHub).
To upgrade an app to the latest version available, run
sdd upgrade <app>
If you want to upgrade to a specific version, run
sdd upgrade <app>=<version>
Internally, sdd
executes un- and re-installation of the app for upgrading unless a specific upgrade routine has been defined.
The usage of SDD_INSTALL_PREFIX
is the same as for the install
command.
To uninstall an app, run
sdd uninstall <app>
The usage of SDD_INSTALL_PREFIX
is the same as for the install
command.
The commands install
, upgrade
, and uninstall
can take multiple arguments to manage apps, e.g.
sdd install <app1> <app2>=<version> <app3>
List installed apps by running
sdd list
sdd list --installed
List all apps available for management in sdd
with
sdd list --available
List all installed apps that can be upgraded to a more recent version with
sdd list --upgradable
The list
command options come in short forms, too: -i
, -a
, -u
High-level program output during management is forwarded to the terminal. Output of the sdd_*
functions of the app management file is in /tmp/sdd-<command>-<app>.stderr
. For increased verbosity when running sdd
, set the respective environment variable before invoking the program
SDD_VERBOSE=1 sdd install <app>
You can always consult
sdd --help
In alphabetical order:
Name | Description |
---|---|
bat | A cat(1) clone with syntax highlighting and Git integration |
borg | Deduplicating archiver with compression and authenticated encryption |
broot | A new way to see and navigate directory trees |
circleci | Use CircleCI from the command line |
dasel | Query and update data structures from the command line |
delta | A syntax-highlighter for git and diff output |
diff-so-fancy | Human readable diffs |
direnv | Handle environment variables depending on current directory |
docker-compose | Define and run multi-container applications with Docker (v2) |
dust | A more intuitive version of du in rust |
fd | A simple, fast and user-friendly alternative to 'find' |
ffsend | Easily and securely share files from the command line |
gh | GitHub's official command line tool |
gitui | blazing fast terminal-ui for git written in rust |
git-trim | Automatically trims your branches whose tracking remote refs are merged or stray |
go | The Go programming language |
hub | Command line tool to interact with GitHub |
jira | Simple JIRA command line client in Go |
jq | Command line JSON processor |
ncdu | Disk usage analyzer with ncurses interface |
oh-my-zsh | Framework for managing zsh configuration |
Pandoc | Universal markup converter |
pip | Python package manager |
Python | Python language installed from redistributable builds |
qrcp | Transfer files over wifi from your computer to your mobile device by scanning a QR code |
ripgrep | Line-oriented text search tool |
sdd | Thanks for being here :) |
slack-term | Slack client for your terminal |
ShellCheck | A static analysis tool for shell scripts |
shfmt | A shell parser, formatter, and interpreter (sh/bash/mksh) |
Telegram | Telegram Desktop messaging app |
wuzz | Interactive cli tool for HTTP inspection |
xh | Friendly and fast tool for sending HTTP requests |
xsv | A fast CSV command line toolkit written in Rust |
You can both
- define app management files for apps that are not shipped with
sdd
, and - extend app management files for apps that are shipped with
sdd
.
The procedure in either case is:
- Create an empty bash file named after the app in
~/.config/sdd/apps
(without.bash
extension). - Add the functions
sdd_install
andsdd_uninstall
with respective functionality. It's mandatory to add a function, even if without functionality (definesdd_uninstall() { return; }
). - Optionally, you can add an
sdd_upgrade
function. It will be executed for upgrading, instead ofsdd_uninstall
followed bysdd_install
. - You're able to manage the app as described in the 'Usage' section.
sdd
tells you when it found a customization for the app specified on the command line.
For exemplary files, see my personal definitions and extensions here.
It is distinguished between
- framework files,
- app management files,
- testing files, and
- project meta-files.
- Framework files contain the logic to run the program. They provide generic utility methods (generating symlinks, reading environment variables, etc.). Examples are: program executable, library files.
- App management files contain instructions to manage specific apps. For each app, at least one management file exists. A management file contains at least methods for installing, upgrading, and uninstalling an app. Management files are organized in directories indicating their level (user or root).
- Testing files cover the functionality of both the framework and the app management files. They are executed in an isolated environment.
- Project meta-files comprise documentation files, configuration files for development tools, an installation script, among others.
git
docker
python3
- optionally:
docker-compose
Clone this repository and pull the Docker image to enable testing and style-checking.
git clone https://github.com/pylipp/sdd
docker pull pylipp/sdd
Set up the local environment for style-checking using the pre-commit framework.
test/setup/venv
The program is tested in a container environment using the bats
framework. Invoke the test runner by
test/run.sh
You might want to skip app tests since they require an internet connection
NO_APP_TESTS=1 test/run.sh
For attaching to the test container after the tests have completed, do
test/run.sh --debug
For running specific tests (paths relative to repository root)
test/run.sh test/apps/fd.bats test/apps/sdd.bats
For creating a Docker container and attaching it to the terminal, do
test/run.sh --open
For style checking, run
test/run.sh --style
For building the image, run
docker build test/setup -t sdd:latest
You can also build and test the image in a single command by
docker-compose -f test/setup/docker-compose.test.yml up
Note that DockerHub automatically builds the image when source code is pushed to GitHub, and pushes it the DockerHub repository if the tests succeeded. The tests are defined in test/setup/docker-compose.test.yml
.
You're looking for managing an app but it's not included in sdd
yet? Here's how contribute an app management script:
- Fork this repository.
- In your fork, create a feature branch.
- Create an empty bash file named after the app in
lib/sdd/apps/user
. - Add a test in
test/apps/<app>.bats
, e.g. verifying the version of the app to be installed. - Add the functions
sdd_install
andsdd_uninstall
with respective functionality. - Add app name, link, and description to the table of available apps in the README file.
- Add the new files, commit, and push.
- Open a PR!
- Update Changelog.
- Run
./release VERSION
Use case | Tool |
---|---|
Managing Python packages (system-wide or user-specific) | pip |
Managing Python apps (system-wide or user-specific) | pipx |
Generate packages from Makefile and track installation by package manager | CheckInstall |
Declarative whole-system configuration; unprivileged package management | GNU Guix |
Creating packages of various formats | fpm |
Note that maintaining packages (deb, rpm, etc.) might still require root privileges, depending on your system.