Skip to content

20261013 - cMeta v0.37.0: the words of the command line are read by what a command expects - #60

Merged
gfursin merged 2 commits into
mainfrom
dev
Oct 13, 2026
Merged

gfursin merged 2 commits into
mainfrom
dev

Conversation

@gfursin

@gfursin gfursin commented Oct 13, 2026

Copy link
Copy Markdown
Member

cMeta v0.37.0: the words of the command line are read by what a command expects.

  • For the parameters a command annotates bool (sort: bool = False, as --help shows), --sort=no now hands it False: yes/no, true/false, on/off and 1/0 in any case are booleans, and any other word is an error naming the parameter and the command. Before, the command got the string 'no', which is true. A parameter without the annotation gets the text as it is; the Python API and nested calls are never read.
  • A category can describe the sensitive parameters of a command in its _cmeta (cli_params, per command: a type among bool, int, float and str, allowed values, a min and a max); the engine converts and checks exactly those.
  • Two switches keep the words text as before: CMETA_CLI_TYPES=off for a process, cli_types: false in a category's _cmeta.
  • The helper utils.cli.typed_params_from_cli is also called by the cmeta-aops task category for a task's run() (cmeta-aops 0.46.0), so --x=no and --use.<key>.x=no reach tasks as booleans too.
  • Tests: tests/core_tests/test_cli_typed_params.py. Docs: using-cmeta.md 3.5, common-commands.md, README, the use-cmeta-cli skill. See CHANGELOG.md.

Verified on Windows, Ubuntu (Python 3.14, 3.9 and the free-threaded 3.14t), macOS, WSL2 and eight Linux images (python 3.9 / 3.14 / 3.15-rc, Ubuntu 22.04 / 24.04, Debian bookworm, Fedora 42, Alpine 3.21): the full engine and cmeta-aops suites.

🤖 Generated with Claude Code

gfursin and others added 2 commits October 13, 2026 18:05
…ool annotation gives a boolean, a described parameter its type, values and range

For the parameters a keyword-style command annotates `bool`, `--sort=no` now hands it False: yes/no,
true/false, on/off and 1/0 in any case are booleans, and any other word is an error naming the parameter
and the command. Before, the command got the string 'no', which is true - a latent bug in every such
parameter. A parameter without the annotation gets the text as it is; the Python API and nested calls
pass Python values and are never read.

A category can describe the sensitive parameters of a command in its _cmeta (`cli_params`, per command:
a type among bool, int, float and str, allowed `values`, a `min` and a `max`); the engine converts and
checks exactly those, the gradual way. Two switches keep the words text as before: CMETA_CLI_TYPES=off
for a process, `cli_types: false` in a category's _cmeta.

utils/cli.py: cli_types_enabled(), bool_params_of() (the signature read once per function; the
forward-reference form of Python 3.14's lazy annotations), typed_params_from_cli(); core.py: the call
before a keyword-style function, for the request the command line made. The aops task category calls
the same helper for a task's run(), so the words reach tasks and their sub-tasks (--use) as booleans too.

Tests: tests/core_tests/test_cli_typed_params.py (the word table, the errors, string annotations, a
bound method, the described parameters, both switches; a category of each style through the API and
the command line; python -m cmeta end to end). Docs: using-cmeta.md 3.5, common-commands.md, README,
the use-cmeta-cli skill, CHANGELOG.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: Grigori Fursin <gfursin@gmail.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: Grigori Fursin <gfursin@gmail.com>
@gfursin
gfursin merged commit e859438 into main Oct 13, 2026
18 of 19 checks passed
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