What felt rough
While trying the installed runseal v0.1.0-beta.13 from a repo that does not have a profile, the first-run path is harsher than it needs to be.
1. Internal help is unreachable without a profile
From a directory without runseal.toml|yaml|yml|json and without ~/.runseal/profiles/default.*:
runseal @profile --help
runseal @resolve --help
runseal @wrappers --help
runseal @which --help
Expected: help text prints, because these are documentation/introspection requests.
Actual: profile discovery runs first and fails with profile file not found.
This is especially noticeable because top-level runseal --help explicitly says:
Run runseal @profile --help, @resolve --help, @wrappers --help, or @which --help for details.
That advice only works after the user is already in a directory with a valid profile.
2. Profile-missing output is correct but noisy for first contact
The current error prints every searched ancestor and every default-profile candidate. That is useful for debugging discovery, but on first contact it is a wall of paths.
A shorter primary message plus an optional hint would be easier to act on, for example:
Error: no runseal profile found from <cwd> upward and no default profile under <RUNSEAL_PROFILE_HOME>.
Hint: create runseal.toml here, pass --profile <path>, or add <RUNSEAL_PROFILE_HOME>/default.toml.
The full searched list could still be available behind a verbose mode, or retained after the hint if that is preferred.
3. No-profile internal commands all fail the same way
Commands like @wrappers and @which probably do need the selected profile directory because profile-local wrappers shadow home wrappers. But when there is no profile, the current failure does not distinguish between:
- commands that could show help without a profile
- commands that need profile context to produce real output
At minimum, --help should bypass profile loading. If the product wants to stay strict for actual output, that still fits the explicit-profile model.
Reproduction
mkdir -p /tmp/runseal-empty
cd /tmp/runseal-empty
RUNSEAL_HOME=/tmp/runseal-home runseal @profile --help
Expected: Usage: runseal @profile help text.
Actual: Error: profile file not found. searched: ....
Notes
The profile-backed paths worked well once a profile existed:
runseal @profilerunseal @resourcesrunseal @resolve resource:// resource://tmprunseal @wrappersrunseal @which :release- external command env/resource injection
So this issue is only about help/error UX before a profile is available, not about changing the core command model.
What felt rough
While trying the installed
runseal v0.1.0-beta.13from a repo that does not have a profile, the first-run path is harsher than it needs to be.1. Internal help is unreachable without a profile
From a directory without
runseal.toml|yaml|yml|jsonand without~/.runseal/profiles/default.*:Expected: help text prints, because these are documentation/introspection requests.
Actual: profile discovery runs first and fails with
profile file not found.This is especially noticeable because top-level
runseal --helpexplicitly says:That advice only works after the user is already in a directory with a valid profile.
2. Profile-missing output is correct but noisy for first contact
The current error prints every searched ancestor and every default-profile candidate. That is useful for debugging discovery, but on first contact it is a wall of paths.
A shorter primary message plus an optional hint would be easier to act on, for example:
The full searched list could still be available behind a verbose mode, or retained after the hint if that is preferred.
3. No-profile internal commands all fail the same way
Commands like
@wrappersand@whichprobably do need the selected profile directory because profile-local wrappers shadow home wrappers. But when there is no profile, the current failure does not distinguish between:At minimum,
--helpshould bypass profile loading. If the product wants to stay strict for actual output, that still fits the explicit-profile model.Reproduction
mkdir -p /tmp/runseal-empty cd /tmp/runseal-empty RUNSEAL_HOME=/tmp/runseal-home runseal @profile --helpExpected:
Usage: runseal @profilehelp text.Actual:
Error: profile file not found. searched: ....Notes
The profile-backed paths worked well once a profile existed:
runseal @profilerunseal @resourcesrunseal @resolve resource:// resource://tmprunseal @wrappersrunseal @which :releaseSo this issue is only about help/error UX before a profile is available, not about changing the core command model.