Roadmap: #1
Problem
The current public install story still assumes either:
- an existing Erlang/OTP runtime so users can run the released escript, or
- an existing Gleam project so users can invoke
gleam run -m sqlode.
That is a much higher-friction entry point than sqlc, especially for users evaluating sqlode before they have committed to a Gleam stack.
Evidence
README.md lists only two install paths: released escript or gleam add sqlode + gleam run
.github/workflows/release.yml uploads a single sqlode escript artifact
- The generated release notes also tell users to download the escript and mention the Erlang/OTP runtime requirement
Expected
Provide at least one first-class install route that does not require users to already have Erlang/OTP or a local Gleam project.
Examples:
- publish a Homebrew tap formula
- ship standalone native binaries
- add an installer path that bundles the runtime
Keeping the escript path is fine, but it should not be the only public-facing option.
Why this matters
Public release adoption depends heavily on first-run friction.
sqlc users are used to brew install sqlc-level convenience, so the current install story will make evaluation slower and less likely.
Roadmap: #1
Problem
The current public install story still assumes either:
gleam run -m sqlode.That is a much higher-friction entry point than
sqlc, especially for users evaluatingsqlodebefore they have committed to a Gleam stack.Evidence
README.mdlists only two install paths: released escript orgleam add sqlode+gleam run.github/workflows/release.ymluploads a singlesqlodeescript artifactExpected
Provide at least one first-class install route that does not require users to already have Erlang/OTP or a local Gleam project.
Examples:
Keeping the escript path is fine, but it should not be the only public-facing option.
Why this matters
Public release adoption depends heavily on first-run friction.
sqlcusers are used tobrew install sqlc-level convenience, so the current install story will make evaluation slower and less likely.