docs(readme): add installation info and add some ideas

This commit is contained in:
xeruf 2022-07-25 16:08:01 +02:00
parent d764b2a43e
commit a7746daf0a

101
README.md
View file

@ -1,4 +1,4 @@
# instalee # Instalee
Inspired by [pass](passwordstore.org "The standard Unix password manager") Inspired by [pass](passwordstore.org "The standard Unix password manager")
and the Unix philosophy and the Unix philosophy
@ -23,21 +23,30 @@ on any system with a POSIX Shell available
you could easily port it to another foundation, you could easily port it to another foundation,
preserving the file structure). preserving the file structure).
## Guiding Principles
instalee closely follows the UNIX philosophy with directory structures and files as configuration.
The goal is to be as generic as possible to accomodate any kind of setup.
However, it should be efficient while generic,
preventing repetition at every level (DRY).
## Usage ## Usage
### Installation
To try Instalee with some pre-configured options,
clone or download the repository and run the included script.
Currently this supports Debian- and Arch-based systems,
as well as a few packages via *snap*, *cargo* and custom scripts
usually imported from the original project site.
Alternatively, you can download just the [`instalee`](./instalee) script
and configure it yourself.
On Arch you can install the script to `/usr/bin`
and the man-page with the `instalee-git` AUR package.
An install helper for Windows,
that prepares chocolatey either on- and offline
and installs git bash, is in the works.
### Configuration ### Configuration
All configuration is stored in `INSTALEE_HOME` All configuration is stored in `INSTALEE_HOME`
which defaults to `$XDG_CONFIG_HOME/instalee` which defaults to the first available of
or the current directory. `$XDG_CONFIG_HOME/instalee` or the current directory.
First, customize the _handlers_ available on your system First, customize the _handlers_ available on your system
in `$INSTALEE_HOME/handlers.available` in `$INSTALEE_HOME/handlers.available`
@ -45,7 +54,7 @@ which is a newline-separated list of values
that usually correspond to subdirectories of the `handlers` directory. that usually correspond to subdirectories of the `handlers` directory.
The _handlers_ are tried in the order they are listed. The _handlers_ are tried in the order they are listed.
Keep the following in mind when configuring instalee: Keep the following in mind when configuring Instalee:
- `handlers.available` is a system-specific file, - `handlers.available` is a system-specific file,
for sensible syncing across many different machines for sensible syncing across many different machines
a mechanism such as [yasm alternate files](https://yadm.io/docs/alternates) a mechanism such as [yasm alternate files](https://yadm.io/docs/alternates)
@ -59,19 +68,19 @@ Keep the following in mind when configuring instalee:
This repository contains an example configuration as used by the author. This repository contains an example configuration as used by the author.
See the [man page](instalee.1) for more details. See the [man page](instalee.1) for more details.
### Installation ### Installing Packages
`instalee <target>` `instalee <target>`
A _target_ may either be a _package_ or a _group_. A _target_ may either be a _package_ or a _group_.
*Instalee* first checks for a `groups/<target>` file. Instalee first checks for a `groups/<target>` file.
A _group_ is a newline-separated list of packages to install, A _group_ is a newline-separated list of packages to install,
which *instalee* then resolves individually. which instalee then resolves individually.
One difference here is that it will try the first handler for the package One difference here is that it will try the first handler for the package
if it has no associated definition. if it has no associated definition.
When there is no corresponding _group_, When there is no corresponding _group_,
*instalee* searches for the first available _handler_ instalee searches for the first available _handler_
with a corresponding entry at `packages/<target>/<handler>`, with a corresponding entry at `packages/<target>/<handler>`,
piping it into the _handler_ to install the package. piping it into the _handler_ to install the package.
The package definition may be an empty file The package definition may be an empty file
@ -79,57 +88,79 @@ The package definition may be an empty file
in which case the name of the package is passed to the _handler_. in which case the name of the package is passed to the _handler_.
Note that both _groups_ and package entries can be executable files, Note that both _groups_ and package entries can be executable files,
in which case *instalee* will execute them and use their output instead, in which case instalee will execute them and use their output instead,
so watch the file permissions! so watch the file permissions!
If an available _handler_ has no definition in `handlers`, If an available _handler_ has no definition in `handlers`,
the package file _has to be_ executable, the package file _has to be_ executable,
as *instalee* will then simply execute it. as instalee will then simply execute it.
### Handlers ### Handlers
Though not required, Though not required,
a typical handler will accept a typical handler will accept a list of packages to install as arguments,
a newline-separated list of packages to install,
enabling batching and the consolidation of interdependent packages into one unit. enabling batching and the consolidation of interdependent packages into one unit.
When installing a package and there is no handler available, When installing a package and there is no handler available,
but a package with the name of a handler of the package has an installable candidate, but a package with the name of a handler of the package has an installable candidate,
the handler will be installed, made available and used. the handler will be installed, made available and used.
## Features When installing packages from groups without candidate,
- Cross-handler dependencies (e.g. logcli script needs go) the first available handler will be tried regardless
-> currently implemented with `HANDLER_depends` files so default-named packages do not always need to setup explicitly
(TODO: Auto-update repo if that succeeds with flag to disable,
flag for manual installation).
### What instalee is not ## Guiding Principles
Instalee closely follows the UNIX philosophy with directory structures and files as configuration.
The goal is to be as generic as possible to accomodate any kind of setup.
However, it should be efficient while generic,
preventing repetition at every level (DRY).
### What Instalee is not
- a (central) package repository containing package sources - a (central) package repository containing package sources
- a package manager to inspect or remove packages - a package manager to inspect or remove packages
- a tool to upgrade all installed packages from various sources - - a tool to upgrade all installed packages from various sources -
see `topgrade` see `topgrade`
## Features
A loose list of undocumented features
and ideas that need to be fleshed out.
- Cross-handler dependencies (e.g. logcli script needs go)
-> currently implemented with `HANDLER_depends` files
### Planned ### Planned
- detection mechanism for handlers and features - detection mechanism for handlers and features
(e.g. whether they support batching) (e.g. whether they support batching)
- helper/hook for adding packages to groups upon install - helper/hook for adding packages to groups upon install
(at least for `pacman`) (at least for `pacman`)
### TODOs
- Debug corner cases
- Handler preparation - update repos and cache last update time in /tmp
- Handler providers e.g. different make mechanisms on arch and debian
- Run file in tempdir by default?
- Handler for downloaded scripts (e.g. passff-host, funkwhale)
- Ability to use multiple repos, including remote - Ability to use multiple repos, including remote
- Log Installs for reuse - Log Installs for reuse
- AUR: Install man-page, Readme to /usr/share/doc
### Windows ### Random TODOs
- Debug corner cases
- Handler preparation - update repos and cache last update time in /tmp
- Run file in tempdir by default?
- Handler for downloaded scripts (e.g. passff-host, funkwhale)
#### Windows
- Install choco and git offline - Install choco and git offline
- Run in git bash - Run in git bash
- Use choco/choco-offline sources - Use choco/choco-offline sources
### Flow ### Flow
This is a revamped concept that would ease setting up new devices with different systems This is a revamped concept
that would ease setting up new devices with different systems
by adding a mapping of functions to applications by adding a mapping of functions to applications
as well as handlers to providers. as well as handlers to providers
(e.g. different make mechanisms on Arch and Debian).
That way, the same functionality is available everywhere,
but can be provided by different packages
as different systems have different users.
The following tables lists some real-world examples to consider, The following tables lists some real-world examples to consider,
but the details still need to be fleshed out. but the details still need to be fleshed out.
@ -159,3 +190,5 @@ but the details still need to be fleshed out.
+ how about `providers/<handler>/<provider>[_<ext>]`? + how about `providers/<handler>/<provider>[_<ext>]`?
Same duplication issue, now spread out... Same duplication issue, now spread out...
+ underscore extension might be superfluous through that, since `ext` was somewhat a proxy for a proper `provider` configuraion + underscore extension might be superfluous through that, since `ext` was somewhat a proxy for a proper `provider` configuraion
- Use system subdirectories for handlers and groups,
which are used by default when system is detected