shed

SelfHostED

langs	(Elisp Makefile Org Rust Toml)

file	size	updated
build.rs	796	2021-11-20-02:24
Cargo.toml	1.4K	2021-11-11-00:11
lisp	14	2021-11-15-00:35
makefile	424	2021-11-21-23:25
readme.org	8.8K	2021-11-24-03:12
rustfmt.toml	52	2021-10-19-02:45
src	176	2021-11-22-00:05

Roadmap

NEXT Registry

• Domain -> Namespace -> ID
• [Domain/Namespace]:ID index tables for quick DHT-style lookups of resource
• Namespaces sharing the same Domain share the same Registry
• For a similar concept, see RedoxOS URLs

HACK Commands

clean

shed clean

• if CWD is a project directory, perform clean script from config.
• elif INPUT is a project name, perform clean script from config.
• elif cache !empty clean global cache.
• else say ‘nothing to clean’.

• ARGS

  --lab [LAB]

  clean the specified lab environment

  --project [PROJECT]

  clean the specified project

  --stash

  clean the stash

  --store

  clean the store

  --all

  clean everything

test

• shed test
  • if CWD is project directory, perform test script from config.
  • elif INPUT is project name, perform test script from config.
  • else say ‘nothing to test’
• ARGS
  • --all => test everything

list

shed list

INPUT

projects, labs, stash, store

• else list service stats

Krypt

• based on intuitions from crypto_box

Babel

shed.el

• daemon <-> process IPC
• bindat protocol definitions
• network daemon messages and packets

Programs

• shc
  • CLI client
  • used to interact with the services
• shx
  • programming environments (REPLs)
    • embedded Python (RustPython)
    • APLs (BQN, k6/9, Gnu/Dyalog APL)
    • Elisp (ielm.el)
    • Erlang (erl)
    • Lua
• shk
  • krypt service
  • reasonably safe secret storage
    • Wireguard, SSH, TLS, plaintext
• she
  • emacs daemon service
• shd
  • prime daemon service
• shs
  • HTTP service daemon

Installation

Once the binary is installed, run shc init -p to bootstrap a via prompts. The default config path is determined by the $SHED_CFG environment variable or $HOME/.config/shed.cfg.

Some commands run just fine without writing a config to disk - A default configuration is supplied when shed.cfg can’t be found. Other commands may panic in the event that a system or internal path dependency is missing.

Configuration

Global configuration is controlled by the Config struct. The specification is non-exhaustive and can be extended by the user at runtime or in code at compile.

pub struct Config {
  pub path: PathBuf,
  pub src: Vec<PackageConfig>,
  pub bin: Vec<ProgramConfig>,
  pub net: NetworkConfig,
  pub hg: MercurialConfig,
  pub lab: Vec<ProjectConfig>,
  pub usr: UserConfig,
}

Configs can be deserialized from RON, JSON, or Bincode formats. I prefer RON for writing local configuration, but feel free to use JSON instead. Bincode is intended for shed internal processes such as IPC and database storage, but exposed to the user for convenience.

• RON

  // cfg.ron
  #![enable(implicit_some)]
  (
    path: "~/shed",
    src: [],
    bin: [],
    net: (
      socket: "127.0.0.1:0",
      tunnel: None,
      engine: Http,
      peers: None,
    ),
    hg: (
      ui: {},
      extensions: None,
      paths: None,
      web: (
        name: "",
        contact: "",
        description: "",
        extensions: [],
        socket: "0.0.0.0:0",
        paths: {},
      ),
    ),
    lab: [],
    usr: (
      shell: (
        env: {},
        cmds: {},
        shell: Bash,
      ),
      geo: None,
      displays: None,
      packages: [],
      projects: [],
      auth: [],
    ),
  )
      

• JSON

  {
    "path": "/home/ellis/shed",
    "src": [],
    "bin": [],
    "net": {
      "socket": "127.0.0.1:0",
      "tunnel": null,
      "engine": "Http",
      "peers": null
    },
    "hg": {
      "ui": {},
      "extensions": null,
      "paths": null,
      "web": {
        "name": "",
        "contact": "",
        "description": "",
        "extensions": [],
        "socket": "0.0.0.0:0",
        "paths": {}
      }
    },
    "lab": [],
    "usr": {
      "shell": {
        "env": {},
        "cmds": {},
        "shell": "Bash"
      },
      "geo": null,
      "displays": null,
      "packages": [],
      "projects": [],
      "auth": []
    }
  }
      

• BIN

  00000000: 1000 0000 0000 0000 2f68 6f6d 652f 656c  ......../home/el
  00000010: 6c69 732f 7368 6564 0000 0000 0000 0000  lis/shed........
  00000020: 0000 0000 0000 0000 0000 0000 7f00 0001  ................
  00000030: 0000 0001 0000 0000 0000 0000 0000 0000  ................
  00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
  00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
  00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
  00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
  00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
  00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
  000000a0: 0000 0000 0000 0000 0000 0a              ...........
      

Commands

shc --help

contrib

• what – Third-party code and dependencies with mirrored source trees
• why – isolation of external dependencies
• src

crater

• what – a private crate registry for the Rust programming language.
• src

The crates.io package registry provides a number of excellent crates, integrates well with the cargo development tool, and should be preferred in all cases. I use crater when I need to:

• import my unpublished crates
• import the master branch of a published crate
• import a local or patched version of a published crate
• import a non-git crate (hg)

crater also works well in intranet/local environments, and can be deployed for use in the following ways:

remote

same as crates.io, registry index is publicly hosted on GitHub (default)

local

registry index is stored locally, crates are retrieved remotely

static

registry index and crate sources are stored locally, no network requests are required