Skip to content

cli: shell subcommands over the HTTP API - #33

Open
vynulldev wants to merge 1 commit into
mainfrom
cli
Open

cli: shell subcommands over the HTTP API#33
vynulldev wants to merge 1 commit into
mainfrom
cli

Conversation

@vynulldev

Copy link
Copy Markdown
Owner

What & why

The HTTP API was curl-only from the shell. The binary now doubles as a client for a running server: vynull search (with --json for fzf/rofi/jq pipelines), add, load, players, playlists, and status. --addr / VYNULL_ADDR select the server, defaulting to the default listen address. A bare vynull (or a flags-only invocation) starts the server exactly as before; subcommands dispatch before any server flag parsing.

The point is scriptability without us writing more frontends: search --json piped through jq and fzf is how shell users build their own pickers, watch-folder cron jobs can call add, and status-bar widgets can poll players --json. Deliberately thin by design: no new server surface at all, every subcommand wraps an existing endpoint, so the CLI can never drift from what the web UI does. No CLI framework either, just stdlib flag handling in one file.

Two behaviours worth reviewing: load accepts a track ID or a search query, and a query must match exactly one track (the candidates are listed on stderr otherwise), because loading the wrong track on a live deck is not a failure mode to leave open. And paths passed to add are resolved on the server's filesystem, which the README documents as a same-host (or shared-mount) assumption rather than pretending to be an upload feature.

Covered by a new e2e scenario driving the built binary's subcommands against a real server: add then analyzed then search finds the track with its exact BPM, --json output parses, an empty search exits zero, and load's error paths fail cleanly (bad deck number, unknown query, no CDJ on the link). Errors go to stderr with exit 1.

Hardware testing

  • Tested on: N/A for the deck side with one caveat: the load success path ends at the existing /api/load endpoint, whose deck behaviour is unchanged; the CLI-specific paths around it (ID/query resolution, deck validation, no-deck error) are covered by the e2e scenario. Worth one vynull load <id> <deck> against a real CDJ when convenient, as a smoke of the plumbing end to end.

Checklist

  • go build ./..., go vet ./..., and go test ./... pass
  • gofmt -l . is clean
  • New source files carry an SPDX header (GPL-3.0-or-later)
  • Tested on real hardware (deck + firmware noted above), or this change doesn't affect deck behaviour
  • I agree my contribution is licensed under the project's GPLv3

The HTTP API was curl-only from the shell. The binary now doubles as a
client for a running server: search (with --json for fzf/rofi/jq
pipelines), add, load (by ID or by a query that must match exactly one
track, listing the candidates otherwise), players, playlists, and
status. --addr / VYNULL_ADDR select the server; defaults to the
default listen address. A bare vynull (or flags-only invocation)
starts the server exactly as before - subcommands dispatch before any
server flag parsing.

Deliberately thin: no new server surface, every subcommand is a
wrapper over an existing endpoint, and paths passed to add are
resolved on the server's filesystem (documented same-host
assumption). Errors land on stderr with exit 1; empty results are not
errors.

Covered by an e2e scenario driving the built binary's subcommands
against a real server: add -> analyzed, search human + json, status,
playlists, and load's error paths (bad deck, unknown query, no CDJ
on the link). The load success path needs a deck to accept the
command and stays a hardware check.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant