tetsuya 0.2.1
Plotly graph export library
Requires Python: >=3.12

# tetsuya

tetsuya collects information and offers it up as JSON packets and pretty
print strings.

It's *very* easy to extend:

- Write a function (a *service*) that collects information from web/system.
  - It takes a `dataclass` as a *config* object (can be empty).
  - It returns another `dataclass` as a *report*.

tetsuya offers the *report* object to your user (and your user only) as a JSON
endpoint available via REST and command-line interface.

You will also define two functions on your *report* dataclass: `short()` and
`long()` which can pretty-print the JSON.

It does some helpful stuff automatically:

1. tetsuya can cache your new *service* for you and auto-refresh the cache: all
   tetsuya service configs have a cachelife integer and autorefresh boolean.

2. tetsuya will derive the default config from your `dataclass`, but will read a
   .toml if you want to change it.

3. tetsuya runs in a client-server model, with a background daemon doing the
   work, and a CLI interface for basic control.

Try `uvx tetsuya --help-tree=ascii` to see the whole interface.

## Installation

### Daemon on systemd

Theres a *tetsuya.service* file in the repository.

```bash
mkdir -p ~/.config/systemd/user

systemctl --user daemon-reload
systemctl --user enable --now "$(realpath ./tetsuya.service)"

loginctl enable-linger "$USER" # (allow it to start at boot even if logged out)

journalctl --user -u tetsuya -f
```

## Roadmap

I think service manager needs to be part of core, and needs to be split into
an interface_api subpacket (cli+daemon) which imports the typers/routers from
further submodules per section and combines them into one.

Then there would be a subpackage of course services.
Note for doing updates:

```bash
if which yay 1> /dev/null; then
  (
  set -e
  yay -Qu
  yay -Pw
  checkupdates
  )
fi
```

- [ ] Some early modules:
  - [ ] Do a Basic 200 is it good thing
    - [ ] Check domains for email record
    - [ ] Check SLL
  - [ ] Active sessions on linux
  - [ ] Updates available
    - [ ] Changelog on kernel
- [ ] Any errors on systemd + --kernel
- [ ] Monarch Money from that guy? - MoneyFlown and redeploy
- [ ] Improve naming and arguments, flags, etc.
  - [ ] -> Services to Client
  - [ ] Names of services = arguments
  - [ ] Add help descriptions
  - [ ] Turn off options like --thing, --no-thing, if --no-thing is default?
  - [ ] Go back to CLI and do the formatting better
- [ ] Document throughout code
- [ ] If we want to instantiate multiple instances of one service class:
- [ ]  Inspect:
  - [ ] all instances of get_name()
  - [ ] how services are registered
  - [ ] Consider Dictionary Storage and Access Here:
    - [ ] `_config.config_data`
    - [ ] `_timer.timer_tasks`
    - [ ] `service manager.??` (Not written at this time)
  - [ ] Will have to pass both service obj + class to _config, _timer
  - [ ] Make room for customed name in config + `.get_name()`
  - [ ] Start will have change (calls a lot of this stuff)
- [ ] Don't enable service until it has a config
  - [ ] Allow per app config default generation
  - [ ] Upon reload, recalculate active services
  - [ ] Config API:
    - [ ] Separate Touch and Dump
- [ ] Create persistence:
  - [ ] Roundtrip reports upon registering (json and back)
  - [ ] Save reports upon running
  - [ ] Load reports upong starting
- [ ] Services can subscribe to changes of other services
- [ ] Importing modules dynamically from a subfoler

### Desired Modules

- [ ] Google drive auditor, google accounts/emails
- [ ] Check agreements (modules subscribed to other modules)
  - [ ] are we checking all domains that namecheap lists
  - [ ] does google list all
- [ ] Analytics summary + link
- [ ] Git status
- [ ] Scrape forum posts
- [ ] Firewall stats
- [ ] process accounting?

### Docs Needed

- Examples in how its used
- Browsing available services
- Activating a new service
- Controlling inspecting services
- Writing your own service
- Connecting remotely