#01 · developers01 / 05
Put your program in Quiver.
You write a text file that says where your program is downloaded from and what steps install it, you commit it to your repository, and it is published. No account, no review, no reserved names.
You write a text file that says where your program is downloaded from and what steps install it, you commit it to your repository, and it is published. No account, no review, no reserved names.
It does not carry your software inside it. It says where to get it and what to do with it on each operating system. It lives in your repository, next to the code and the pipeline you already have.
arrow.yaml at the root of the repository, or ARROW.md with the Arrow inside an arrow code block. If you want several in one repository, they are grouped into a collection.
Name, description and licence. There is no version field, and that is deliberate: git sets the version.
One recipe per platform inside the same file. The keys are patterns: linux/amd64, windows/*, or * for all of them. A target can inherit from another, and whichever one declares a phase owns it outright.
Up to five phases: install, update, execute, stop and uninstall. If no target declares execute, your Arrow is a program that gets installed; if all of them do, it is a service that runs.
The steps of each phase, in order. run runs a command, fetch downloads a file and can check its hash, signal shuts a process down. Every step carries its title, its timeout and whether a failure aborts.
variables generates the form the user fills in before installing, with types, defaults and validation. netbridge declares the ports your software needs, and Quiver assigns them and tries to open them on the router. A server becomes as installable as a text editor.
tools are Arrows that have to be installed before yours; services, Arrows that have to be running while yours executes. With exports, a dependency publishes a named path and you use it without guessing where it landed.
20 lines, and an application is published.
There is no publish command because there is nowhere to publish to. The file stays in your repository, and that is the whole mechanism.
No registration, no review and no reserved names. Two developers can't claim the same name because the name is the repository.
Your Arrow installs by its address: github.com/user/repository. It is not an entry in a registry, it is the instruction to go to that domain, that user, that repository, and look for the manifest there. GitHub, GitLab, Bitbucket or whichever forge you use.
It is the git tag the file was read at: github.com/user/repository@v1.2.3. With no tag, Quiver resolves the latest stable release and ignores pre-releases.
Tag the repository quiver-arrow from your provider's own interface and it shows up in search. Without the tag it installs exactly the same, by namespace: search filters, it does not admit.
Shipping a new release stays inside the workflow you already have.
What you wrote once is run by a daemon on the machine of whoever installs it, on Linux, macOS and Windows.
quiver install github.com/user/repository in the terminal, or the same namespace from the desktop app, which carries the daemon inside it.
Quiver compiles your manifest before running it and shows the exact list of steps, with their commands, their URLs and the privileges they ask for. It is plain text, versioned and diffable against the previous version.
If your Arrow depends on others, they are resolved and installed first, as one more step in the progress bar. Two versions of the same Arrow coexist instead of negotiating.
A new tag is a new release. An update that fails returns to the previous state, so it never breaks an install that was already working.
You write the file, you commit it, and it can be installed. Nobody has to approve it.
The manifest format is specified in the daemon's repository, with its schema and its validation rules.