errand-run 0.1.1__tar.gz

errand_run-0.1.1/.gitignore

@@ -0,0 +1,22 @@
+runs/
+__pycache__/
+*.pyc
+*.egg-info/
+dist/
+errand-envs.py
+.errand/
+*.exe
+build/
+
+
+# what the examples build when you run them
+examples/*/cpp/test_*
+!examples/*/cpp/test_*.cpp
+!examples/*/cpp/test_*.h
+examples/*/rust/target/
+
+.venv*/
+dist/
+
+# ...except where it is the example
+!examples/*/errand-envs.py

errand_run-0.1.1/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Hugo Leclerc
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

errand_run-0.1.1/Makefile

@@ -0,0 +1,136 @@
+# Building errand, and sending it out.
+#
+# None of this is needed to USE errand: it runs from a checkout, with no install
+# at all and nothing to install. This is for the two other things -- putting it
+# on the PATH of an environment, and publishing it.
+#
+# The release order. Every step is repeatable except the last, which is not:
+#
+#   make test            the suite ( written with errand ) must pass
+#   make build           sdist + wheel, from an emptied dist/
+#   make check           twine's reading of the metadata, strictly
+#   make testpypi        upload to TestPyPI, then install it from there and run it
+#   make tag             git tag v$(VERSION)
+#   make pypi            THE one that cannot be undone: a version number on PyPI
+#                        is spent forever, deleting the file does not free it
+#
+# So the version is bumped in ONE place -- errand/__init__.py -- and everything
+# else, the metadata included, reads it from there.
+
+PY      ?= python3
+VERSION := $(shell sed -n 's/^__version__ = "\(.*\)"/\1/p' errand/__init__.py)
+DIST    := errand-run
+VENV    ?= .venv
+
+# The tools that build and upload live in a virtual environment of their own,
+# built on demand. Publishing must not depend on what happens to be installed
+# on the machine doing it -- and on a system python, pip will rightly refuse.
+TOOLS   := .venv-release
+TOOLSPY := $(TOOLS)/bin/python
+
+.PHONY: help dev venv test build check testpypi pypi tag clean site site-build site-deploy
+
+help:
+	@echo "errand $(VERSION)   ( distribution: $(DIST) )"
+	@echo
+	@echo "  make venv        a virtual environment with errand installed in it, editable"
+	@echo "  make dev         pip install -e .  into the interpreter you are using now"
+	@echo "  make test        run the suite         ( make test ARGS='test_queue.py::*' )"
+	@echo
+	@echo "  make site        the website, live reloading   ( docs/, VitePress )"
+	@echo "  make site-build  the website into docs/.vitepress/dist"
+	@echo "  make site-deploy site-build, then push it to the gh-pages branch ( https://hleclerc.github.io/errand/ )"
+	@echo
+	@echo "  make build       sdist + wheel into dist/"
+	@echo "  make check       twine check --strict"
+	@echo "  make testpypi    upload to TestPyPI"
+	@echo "  make tag         git tag v$(VERSION)"
+	@echo "  make pypi        upload to PyPI -- irreversible"
+	@echo "  make clean       dist/, build artefacts, __pycache__"
+
+# ── using it ────────────────────────────────────────────────────────────────
+
+# Editable, because the interesting install is the one where the checkout IS
+# the package: `errand` on the PATH, and an edit to errand/cli.py takes effect
+# on the next command without reinstalling anything.
+dev:
+	$(PY) -m pip install -e .
+
+venv:
+	$(PY) -m venv $(VENV)
+	$(VENV)/bin/python -m pip install --quiet --upgrade pip
+	$(VENV)/bin/python -m pip install -e .
+	@echo
+	@echo "  . $(VENV)/bin/activate    then: errand --tui"
+
+# PYTHONPATH so this works from a bare checkout too -- the suite is the first
+# thing to run, and having to install something first would be the wrong order.
+test:
+	cd tests && PYTHONPATH=$(CURDIR) $(PY) -m errand run $(ARGS)
+
+# ── the website ─────────────────────────────────────────────────────────────
+#
+# Everything web lives under docs/, including its package.json, so the project
+# root stays a Python package root. `npm install` is idempotent and quick once
+# the modules are there, so there is no separate step to remember.
+
+site: docs/node_modules
+	cd docs && npm run dev
+
+site-build: docs/node_modules
+	cd docs && npm run build
+
+# The built site becomes the only commit of the gh-pages branch ( force-pushed: no history to keep ).
+# .nojekyll, or GitHub Pages drops the _-prefixed files of VitePress. Once, on GitHub:
+# Settings > Pages > Source = "Deploy from a branch", branch gh-pages, folder / ( root ).
+SITE_REMOTE ?= $(shell git remote get-url origin)
+SITE_BRANCH ?= gh-pages
+
+site-deploy: site-build
+	cd docs/.vitepress/dist && touch .nojekyll && rm -rf .git \
+	  && git init -q -b $(SITE_BRANCH) \
+	  && git add -A \
+	  && git commit -q -m "site: $$(cd ../../.. && git rev-parse --short HEAD)" \
+	  && git push -f $(SITE_REMOTE) $(SITE_BRANCH) \
+	  && rm -rf .git
+
+docs/node_modules: docs/package.json
+	cd docs && npm install
+	@touch $@
+
+# ── publishing ──────────────────────────────────────────────────────────────
+
+$(TOOLSPY):
+	$(PY) -m venv $(TOOLS)
+	$(TOOLSPY) -m pip install --quiet --upgrade pip build twine
+
+build: $(TOOLSPY)
+	rm -rf dist
+	$(TOOLSPY) -m build
+
+check: build
+	$(TOOLSPY) -m twine check --strict dist/*
+
+# Credentials: a PyPI API token, in ~/.pypirc or in TWINE_USERNAME=__token__ /
+# TWINE_PASSWORD=pypi-… . Never in this file.
+testpypi: check
+	$(TOOLSPY) -m twine upload --repository testpypi dist/*
+	@echo
+	@echo "  check it came out whole:"
+	@echo "  pip install -i https://test.pypi.org/simple/ $(DIST)==$(VERSION)"
+
+pypi: check
+	@test -z "$$(git status --porcelain)" || { echo "  the tree is not clean -- commit first"; exit 1; }
+	@case "$(VERSION)" in *dev*|*a*|*b*|*rc*) \
+	  echo "  $(VERSION) is a pre-release; say FORCE=1 if that is what you mean"; \
+	  [ -n "$(FORCE)" ] || exit 1 ;; esac
+	$(TOOLSPY) -m twine upload dist/*
+	@echo "  don't forget: make tag"
+
+tag:
+	git tag -a v$(VERSION) -m "errand $(VERSION)"
+	@echo "  git push origin v$(VERSION)"
+
+clean:
+	rm -rf dist build *.egg-info
+	find . -name __pycache__ -type d -prune -exec rm -rf {} +

errand_run-0.1.1/PKG-INFO

@@ -0,0 +1,166 @@
+Metadata-Version: 2.5
+Name: errand-run
+Version: 0.1.1
+Summary: Run work here, in a container or on another machine, and bring back what it produced
+Project-URL: Homepage, https://github.com/hleclerc/errand
+Project-URL: Source, https://github.com/hleclerc/errand
+Project-URL: Issues, https://github.com/hleclerc/errand/issues
+Author: Hugo Leclerc
+License-Expression: MIT
+License-File: LICENSE
+Keywords: benchmark,experiment,hpc,remote,reproducibility,runner
+Classifier: Development Status :: 3 - Alpha
+Classifier: Environment :: Console
+Classifier: Intended Audience :: Developers
+Classifier: Intended Audience :: Science/Research
+Classifier: Operating System :: MacOS
+Classifier: Operating System :: POSIX
+Classifier: Programming Language :: Python :: 3
+Classifier: Topic :: Software Development :: Testing
+Classifier: Topic :: System :: Distributed Computing
+Requires-Python: >=3.10
+Description-Content-Type: text/markdown
+
+# errand
+
+> **errand runs your work in any environment — a conda or uv env, a container, another machine
+> over ssh, a Slurm allocation, any stack of them — building and updating it from what it
+> declares, and syncing your files there and back.**
+
+An *errand* is a trip made on someone's behalf: go there, do the thing, come back with what it
+produced.
+
+```python
+# errand-envs.py
+import errand
+
+errand.envs[ "local" ]   = errand.Env( [ errand.Micromamba( "proj", python = "3.13", requirements = "requirements.txt" ) ] )
+errand.envs[ "cluster" ] = errand.Env( [ errand.Ssh( host = "gpu-box", root = "~/proj" ),
+                                         errand.Slurm( gpus = 1, time = "2:00:00" ),
+                                         errand.Apptainer( image = "cuda.sif", recipe = "cuda.def" ) ] )
+```
+
+```bash
+errand run --env local pytest                       # created and installed on first use
+errand run --env cluster python train.py --lr 1e-3  # rsync, srun, apptainer, and back
+errand run --env cluster --pull out make results    # ...and out/ comes back here
+errand run --env local,cluster ./bench              # in both places, one after the other
+errand shell --env cluster                          # be let in, to look around
+```
+
+The site has everything, split by theme, with tutorials: **<https://hleclerc.github.io/errand/>**
+(built from [`docs/`](docs/)).
+
+## Installing
+
+```bash
+pip install errand-run
+```
+
+The *distribution* is `errand-run` — `errand` on PyPI is somebody else's project — but what you type
+and what you import is `errand`. It has **no dependencies, and is not going to get any**: its job is
+to build the environment the work runs in, so it has to run before any environment exists.
+
+## Environments are stacks of layers
+
+Read outside in: *that machine, an allocation on it, a container, your command.*
+
+| layer | |
+|---|---|
+| `Micromamba`, `Conda`, `Uv`, `Venv` | an interpreter and its packages: `python =`, `requirements =`, `packages =`, `pip =` |
+| `Nix`, `Guix`, `Module` | a flake or a manifest; `module load` the way a cluster picks a toolchain |
+| `Apptainer`, `Docker`, `Podman` | a container, built from its `recipe` when it is missing or changed |
+| `Ssh` | another machine: the project is rsynced there before, what was asked for comes back after |
+| `Slurm`, `Oar`, `Pbs`, `Sge`, `Lsf` | an allocation, sized from what the work asks for |
+| `Windows` | a Windows VM under QEMU that errand installs and boots — MSVC included |
+| `Vars` | environment variables for the child |
+
+**Kept current by themselves.** Before every run, errand compares what each layer declares — a
+Python version, a `requirements.txt`, a container recipe, a pip list — with what it last built, and
+brings it up to date when they have drifted. An environment that already exists the first time
+errand sees it is adopted as it is, never rebuilt on somebody's first command.
+
+```bash
+errand envs              # what is declared, and in what state
+errand setup --dry-run   # what bringing it up to date would run
+```
+
+**Files go there and come back.** Over `Ssh` the project is pushed with rsync before the command
+runs; `--pull DIR` brings a directory back afterwards, and `also = [ "../lib" ]` pushes a sibling
+checkout the work needs. Ask for an output directory with `-o` and it is made over there, handed to
+the command as `$ERRAND_OUT_DIR`, and fetched back here.
+
+**Several places at once.** A comma is several environments, and environments carry tags:
+
+```bash
+errand run --env local,cluster ./bench
+errand run -t cuda ./bench             # every environment tagged cuda
+errand run --fp 32,64 ./bench          # an environment that does not say fp covers both
+```
+
+## What you get on top
+
+- **The machine to yourself when it matters.** errand keeps a queue per host, outside the process:
+  `errand run -x ./bench` waits for what is running and holds everything else back; `--cpus 8`,
+  `--gpus 1` take a share, and a card is assigned, not merely counted. Inside a Slurm allocation
+  errand does not queue — the scheduler already decided.
+- **Let it run.** `errand run --batch …` gives the shell back — a detached session here, a released
+  ssh command there, an `sbatch` on a cluster — and `errand status` / `errand watch` say how it goes.
+- **A record of every run**, in `.errand/`: what ran, where, when, how it ended, what it printed.
+  With `-o`, a directory per run under `runs/`, whose path is computed from the work, the place and
+  the date, so that two machines or two days sit side by side.
+- **One screen for all of it**: `errand tui`, drawn with the standard library's curses.
+
+## Files, suites and entries
+
+What follows `errand run` is read from the command line alone, never guessed:
+
+```bash
+errand run train.py --lr 1e-3          # a .py: run by the python of the place
+errand run ./bench                     # anything else: executed as it is
+errand run make check                  # ...or a command of the place
+errand run 'tests/**::*'               # x::y: the entries of a suite -- pytest, Catch2, cargo
+errand run tests/test_api.py::test_ok  # one of them
+errand run -r bench 'tests/**::*'      # through a runner of the project's own
+```
+
+`x::y` goes to the runner that recognises the file — pytest, Catch2, cargo, or errand's own entries
+— which collects one entry per test, records each, and translates its vocabulary: a
+`@pytest.mark.slow` is a tag that `-e '!slow'` filters on. A project names its own runner
+instances in `errand-project.py`, and says what a bare `errand run` means:
+
+```python
+# errand-project.py
+import errand
+
+errand.runners[ "bench" ] = errand.Pytest( dirs = [ "tests/bench" ] )
+errand.runners.replace( errand.Catch2( dir = "cpp", build = "cmake --build build" ) )
+errand.default_run = [ "tests/**::*", "cpp/**::*" ]
+```
+
+errand also has entries of its own, for work that has no framework — `if test( "name" ):` next to
+the code, with typed parameters and numbers to follow. See
+[Writing entries](https://hleclerc.github.io/errand/guide/declaring-work).
+
+## Configuration
+
+None is needed: `errand run <command>` works in an empty directory. A project's `errand-*.py` files
+sit at its root and are ordinary Python; `errand init` writes a first pair.
+
+| | |
+|---|---|
+| `errand-project.py` | what the project does: runners, `default_run`, `errand.configure( … )`. Versioned |
+| `errand-envs.py` | where it runs: the environments. Versioned when it names no machine |
+| `errand-vars.py` | what only your machine knows — hosts, paths — read first, never versioned |
+
+## Examples
+
+In [`examples/`](examples/): [environments over three machines](examples/01-environments/),
+[an existing pytest / Catch2 / cargo project](examples/02-existing-suite/), and [errand's own
+entries](examples/03-entries/).
+
+## Status
+
+Everything above works and is covered by errand's own suite. Not released: the API may still move.
+How errand's own entries are expressed — needs, numbers to follow, skips — is being reworked into a
+protocol any program can follow ([ADR 0003](docs/adr/0003-run-launches-everything-output-on-request.md)).

errand_run-0.1.1/README.md

@@ -0,0 +1,143 @@
+# errand
+
+> **errand runs your work in any environment — a conda or uv env, a container, another machine
+> over ssh, a Slurm allocation, any stack of them — building and updating it from what it
+> declares, and syncing your files there and back.**
+
+An *errand* is a trip made on someone's behalf: go there, do the thing, come back with what it
+produced.
+
+```python
+# errand-envs.py
+import errand
+
+errand.envs[ "local" ]   = errand.Env( [ errand.Micromamba( "proj", python = "3.13", requirements = "requirements.txt" ) ] )
+errand.envs[ "cluster" ] = errand.Env( [ errand.Ssh( host = "gpu-box", root = "~/proj" ),
+                                         errand.Slurm( gpus = 1, time = "2:00:00" ),
+                                         errand.Apptainer( image = "cuda.sif", recipe = "cuda.def" ) ] )
+```
+
+```bash
+errand run --env local pytest                       # created and installed on first use
+errand run --env cluster python train.py --lr 1e-3  # rsync, srun, apptainer, and back
+errand run --env cluster --pull out make results    # ...and out/ comes back here
+errand run --env local,cluster ./bench              # in both places, one after the other
+errand shell --env cluster                          # be let in, to look around
+```
+
+The site has everything, split by theme, with tutorials: **<https://hleclerc.github.io/errand/>**
+(built from [`docs/`](docs/)).
+
+## Installing
+
+```bash
+pip install errand-run
+```
+
+The *distribution* is `errand-run` — `errand` on PyPI is somebody else's project — but what you type
+and what you import is `errand`. It has **no dependencies, and is not going to get any**: its job is
+to build the environment the work runs in, so it has to run before any environment exists.
+
+## Environments are stacks of layers
+
+Read outside in: *that machine, an allocation on it, a container, your command.*
+
+| layer | |
+|---|---|
+| `Micromamba`, `Conda`, `Uv`, `Venv` | an interpreter and its packages: `python =`, `requirements =`, `packages =`, `pip =` |
+| `Nix`, `Guix`, `Module` | a flake or a manifest; `module load` the way a cluster picks a toolchain |
+| `Apptainer`, `Docker`, `Podman` | a container, built from its `recipe` when it is missing or changed |
+| `Ssh` | another machine: the project is rsynced there before, what was asked for comes back after |
+| `Slurm`, `Oar`, `Pbs`, `Sge`, `Lsf` | an allocation, sized from what the work asks for |
+| `Windows` | a Windows VM under QEMU that errand installs and boots — MSVC included |
+| `Vars` | environment variables for the child |
+
+**Kept current by themselves.** Before every run, errand compares what each layer declares — a
+Python version, a `requirements.txt`, a container recipe, a pip list — with what it last built, and
+brings it up to date when they have drifted. An environment that already exists the first time
+errand sees it is adopted as it is, never rebuilt on somebody's first command.
+
+```bash
+errand envs              # what is declared, and in what state
+errand setup --dry-run   # what bringing it up to date would run
+```
+
+**Files go there and come back.** Over `Ssh` the project is pushed with rsync before the command
+runs; `--pull DIR` brings a directory back afterwards, and `also = [ "../lib" ]` pushes a sibling
+checkout the work needs. Ask for an output directory with `-o` and it is made over there, handed to
+the command as `$ERRAND_OUT_DIR`, and fetched back here.
+
+**Several places at once.** A comma is several environments, and environments carry tags:
+
+```bash
+errand run --env local,cluster ./bench
+errand run -t cuda ./bench             # every environment tagged cuda
+errand run --fp 32,64 ./bench          # an environment that does not say fp covers both
+```
+
+## What you get on top
+
+- **The machine to yourself when it matters.** errand keeps a queue per host, outside the process:
+  `errand run -x ./bench` waits for what is running and holds everything else back; `--cpus 8`,
+  `--gpus 1` take a share, and a card is assigned, not merely counted. Inside a Slurm allocation
+  errand does not queue — the scheduler already decided.
+- **Let it run.** `errand run --batch …` gives the shell back — a detached session here, a released
+  ssh command there, an `sbatch` on a cluster — and `errand status` / `errand watch` say how it goes.
+- **A record of every run**, in `.errand/`: what ran, where, when, how it ended, what it printed.
+  With `-o`, a directory per run under `runs/`, whose path is computed from the work, the place and
+  the date, so that two machines or two days sit side by side.
+- **One screen for all of it**: `errand tui`, drawn with the standard library's curses.
+
+## Files, suites and entries
+
+What follows `errand run` is read from the command line alone, never guessed:
+
+```bash
+errand run train.py --lr 1e-3          # a .py: run by the python of the place
+errand run ./bench                     # anything else: executed as it is
+errand run make check                  # ...or a command of the place
+errand run 'tests/**::*'               # x::y: the entries of a suite -- pytest, Catch2, cargo
+errand run tests/test_api.py::test_ok  # one of them
+errand run -r bench 'tests/**::*'      # through a runner of the project's own
+```
+
+`x::y` goes to the runner that recognises the file — pytest, Catch2, cargo, or errand's own entries
+— which collects one entry per test, records each, and translates its vocabulary: a
+`@pytest.mark.slow` is a tag that `-e '!slow'` filters on. A project names its own runner
+instances in `errand-project.py`, and says what a bare `errand run` means:
+
+```python
+# errand-project.py
+import errand
+
+errand.runners[ "bench" ] = errand.Pytest( dirs = [ "tests/bench" ] )
+errand.runners.replace( errand.Catch2( dir = "cpp", build = "cmake --build build" ) )
+errand.default_run = [ "tests/**::*", "cpp/**::*" ]
+```
+
+errand also has entries of its own, for work that has no framework — `if test( "name" ):` next to
+the code, with typed parameters and numbers to follow. See
+[Writing entries](https://hleclerc.github.io/errand/guide/declaring-work).
+
+## Configuration
+
+None is needed: `errand run <command>` works in an empty directory. A project's `errand-*.py` files
+sit at its root and are ordinary Python; `errand init` writes a first pair.
+
+| | |
+|---|---|
+| `errand-project.py` | what the project does: runners, `default_run`, `errand.configure( … )`. Versioned |
+| `errand-envs.py` | where it runs: the environments. Versioned when it names no machine |
+| `errand-vars.py` | what only your machine knows — hosts, paths — read first, never versioned |
+
+## Examples
+
+In [`examples/`](examples/): [environments over three machines](examples/01-environments/),
+[an existing pytest / Catch2 / cargo project](examples/02-existing-suite/), and [errand's own
+entries](examples/03-entries/).
+
+## Status
+
+Everything above works and is covered by errand's own suite. Not released: the API may still move.
+How errand's own entries are expressed — needs, numbers to follow, skips — is being reworked into a
+protocol any program can follow ([ADR 0003](docs/adr/0003-run-launches-everything-output-on-request.md)).

errand_run-0.1.1/docs/README.md

@@ -0,0 +1,43 @@
+# The errand website
+
+[VitePress](https://vitepress.dev). Everything web lives under this directory, so the project root
+stays a Python package root.
+
+```bash
+cd docs
+npm install
+npm run dev        # http://localhost:5173/errand/
+npm run build      # -> .vitepress/dist
+npm run preview    # serve what was built
+```
+
+From the project root, the Makefile says the same thing: `make site`, `make site-build`.
+
+## The layout
+
+```
+index.md                 the home page: hero, features, the layers, "whatever you test with"
+guide/                   the documentation, by sub-theme
+tutorials/               four walkthroughs, in order; the first three are examples/
+reference/               the flags, the API, the layers, the providers, the files
+.vitepress/config.mts    nav, sidebar, base
+.vitepress/theme/        the CSS that makes it errand's, and `Term.vue` + `scenes.js`: the terminal
+                         recordings (`<Term scene="tui" />`), drawn by hand, cell by cell
+```
+
+`base` is `/errand/`, for GitHub Pages under `github.com/hleclerc/errand`. Change it in
+`config.mts` if the site moves.
+
+## Keeping it true
+
+The README is the source of record for what errand does, and these pages are written from it. When
+a behaviour changes, the page that describes it is part of the change — the build fails on a dead
+internal link, which catches a page that was removed but not the one that went quietly out of date.
+
+Pages that make a claim about a flag or an argument should be checked against `errand/cli.py`,
+`errand/layers.py` and `errand/providers.py`, which are where the answers actually live.
+
+## Publishing
+
+`.github/workflows/docs.yml` builds and deploys on every push to `main` that touches `docs/`. Pages
+has to be switched to "GitHub Actions" as its source once, in the repository's settings.

errand_run-0.1.1/docs/node_modules/@algolia/abtesting/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2013-Present Algolia
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

errand_run-0.1.1/docs/node_modules/@algolia/abtesting/README.md

@@ -0,0 +1,76 @@
+<p align="center">
+  <a href="https://www.algolia.com">
+    <img alt="Algolia for JavaScript" src="https://raw.githubusercontent.com/algolia/algoliasearch-client-common/master/banners/javascript.png" >
+  </a>
+
+  <h4 align="center">The perfect starting point to integrate <a href="https://algolia.com" target="_blank">Algolia</a> within your JavaScript project</h4>
+
+  <p align="center">
+    <a href="https://npmjs.com/package/@algolia/abtesting"><img src="https://img.shields.io/npm/v/@algolia/abtesting.svg?style=flat-square" alt="NPM version"></img></a>
+    <a href="http://npm-stat.com/charts.html?package=@algolia/abtesting"><img src="https://img.shields.io/npm/dm/@algolia/abtesting.svg?style=flat-square" alt="NPM downloads"></a>
+    <a href="https://www.jsdelivr.com/package/npm/@algolia/abtesting"><img src="https://data.jsdelivr.com/v1/package/npm/@algolia/abtesting/badge" alt="jsDelivr Downloads"></img></a>
+    <a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-green.svg?style=flat-square" alt="License"></a>
+  </p>
+</p>
+
+<p align="center">
+  <a href="https://www.algolia.com/doc/libraries/sdk/install#javascript" target="_blank">Documentation</a>  •
+  <a href="https://www.algolia.com/doc/guides/building-search-ui/what-is-instantsearch/js/" target="_blank">InstantSearch</a>  •
+  <a href="https://discourse.algolia.com" target="_blank">Community Forum</a>  •
+  <a href="http://stackoverflow.com/questions/tagged/algolia" target="_blank">Stack Overflow</a>  •
+  <a href="https://github.com/algolia/algoliasearch-client-javascript/issues" target="_blank">Report a bug</a>  •
+  <a href="https://alg.li/support" target="_blank">Support</a>
+</p>
+
+## ✨ Features
+
+- Thin & **minimal low-level HTTP client** to interact with Algolia's API
+- Works both on the **browser** and **node.js**
+- **UMD and ESM compatible**, you can use it with any module loader
+- Built with TypeScript
+
+## 💡 Getting Started
+
+> [!TIP]
+> This API client is already a dependency of [the algoliasearch client](https://www.npmjs.com/package/algoliasearch), you don't need to manually install `@algolia/abtesting` if you already have `algoliasearch` installed.
+
+To get started, you first need to install @algolia/abtesting (or any other available API client package).
+All of our clients comes with type definition, and are available for both browser and node environments.
+
+### With a package manager
+
+```bash
+yarn add @algolia/abtesting@1.25.0
+# or
+npm install @algolia/abtesting@1.25.0
+# or
+pnpm add @algolia/abtesting@1.25.0
+```
+
+### Without a package manager
+
+Add the following JavaScript snippet to the <head> of your website:
+
+```html
+<script src="https://cdn.jsdelivr.net/npm/@algolia/abtesting@1.25.0/dist/builds/browser.umd.js"></script>
+```
+
+### Usage
+
+You can now import the Algolia API client in your project and play with it.
+
+```js
+import { abtestingV3Client } from '@algolia/abtesting';
+
+const client = abtestingV3Client('YOUR_APP_ID', 'YOUR_API_KEY');
+```
+
+For full documentation, visit the **[Algolia JavaScript API Client](https://www.algolia.com/doc/libraries/sdk/methods/abtesting-v3/)**.
+
+## ❓ Troubleshooting
+
+Encountering an issue? Before reaching out to support, we recommend heading to our [FAQ](https://support.algolia.com/hc/en-us/sections/15061037630609-API-Client-FAQs) where you will find answers for the most common issues and gotchas with the client. You can also open [a GitHub issue](https://github.com/algolia/api-clients-automation/issues/new?assignees=&labels=&projects=&template=Bug_report.md)
+
+## 📄 License
+
+The Algolia JavaScript API Client is an open-sourced software licensed under the [MIT license](LICENSE).

errand_run-0.1.1/docs/node_modules/@algolia/autocomplete-core/README.md

@@ -0,0 +1,17 @@
+# @algolia/autocomplete-core
+
+The [`autocomplete-core`](https://www.algolia.com/doc/ui-libraries/autocomplete/api-reference/autocomplete-core/createAutocomplete) package is the foundation of Autocomplete. It exposes primitives to build an autocomplete experience.
+
+You likely don’t need to use this package directly unless you’re building a [renderer](https://www.algolia.com/doc/ui-libraries/autocomplete/guides/creating-a-renderer).
+
+## Installation
+
+```sh
+yarn add @algolia/autocomplete-core
+# or
+npm install @algolia/autocomplete-core
+```
+
+## Documentation
+
+See [**Documentation**](https://www.algolia.com/doc/ui-libraries/autocomplete/api-reference/autocomplete-core).

errand_run-0.1.1/docs/node_modules/@algolia/autocomplete-plugin-algolia-insights/README.md

@@ -0,0 +1,15 @@
+# @algolia/autocomplete-plugin-algolia-insights
+
+The Algolia Insights plugin automatically sends click and conversion events to the [Algolia Insights API](https://www.algolia.com/doc/rest-api/insights]) whenever a user interacts with the autocomplete.
+
+## Installation
+
+```sh
+yarn add @algolia/autocomplete-plugin-algolia-insights
+# or
+npm install @algolia/autocomplete-plugin-algolia-insights
+```
+
+## Documentation
+
+See [**Documentation**](https://www.algolia.com/doc/ui-libraries/autocomplete/api-reference/autocomplete-plugin-algolia-insights).