Skip to content

value_enum is a silent no-op on all kcmc unit flags (no possible-values, cryptic errors); kcl vs file density spellings diverge #1749

Description

@sneg55

value_enum is a silent no-op on every kcmc-typed unit flag (no possible-values, cryptic errors), and zoo file vs zoo kcl accept different density unit spellings

Context: API Makeathon participant. Found while reviewing the unit-flag wiring. This is the root cause and generalization of the already-filed #1744 (which covers zoo kcl volume only).

1. value_enum does nothing on kcmc-typed flags

Many unit and format flags carry #[clap(..., value_enum)] but are typed with kcmc::units::* (or kcmc::ImageFormat / FileImportFormat). The kittycad-modeling-cmds crate has no clap dependency, so those types do not implement clap::ValueEnum. With current clap this does not fail to compile: value_parser! falls back to FromStr and the value_enum attribute silently does nothing. So --help prints no possible values, an invalid value prints only error: invalid value 'x' for '--unit <UNIT>': parse failed, and shell completions complete nothing.

Affected flags (all FromStr-only under the hood):

  • src/cmd_kcl.rs: analyze (all six unit flags), volume, mass (--material-density-unit, --output-unit), density (--material-mass-unit, --output-unit), center-of-mass, surface-area, bounding-box unit flags.
  • src/cmd_file.rs: file snapshot --src-format, --output-format.

By contrast the kittycad::types::* flags on the zoo file volume/mass/density side really derive clap::ValueEnum (the kittycad crate is built with its clap feature), so their --help lists values and their errors enumerate the alternatives.

2. Density unit spelling diverges between file and kcl

zoo file mass|density --material-density-unit (type kittycad::types::UnitDensity) accepts only the kebab spellings lb-ft3 / kg-m3. zoo kcl mass|density --material-density-unit (type kcmc::units::UnitDensity, hand-written FromStr) accepts lbft3 | lb:ft3 | lb-ft3 and kgm3 | kg:m3 | kg-m3. kg:m3 is also the serde/API wire spelling, so the file side rejects the very string the API returns in its own JSON.

Concrete failure

zoo kcl surface-area --help shows --output-unit <OUTPUT_UNIT> with no value list, and zoo kcl mass ... --material-density-unit kgm2 prints only parse failed with no hint that kg:m3 / lb:ft3 are valid. A script that computes mass via zoo kcl mass --material-density-unit kg:m3 then switches to a STEP input with zoo file mass and the same flag breaks with invalid value 'kg:m3'.

Verify

Compare zoo kcl surface-area --help (no possible values) with zoo file surface-area --help (lists them). Run zoo file mass --material-density-unit kg:m3 ... (rejected) versus zoo kcl mass --material-density-unit kg:m3 ... (accepted at parse).

Suggested fix

Implement or derive clap::ValueEnum for the kcmc unit/format enums (or wrap them in local enums that do), and unify the density (and other) unit enums so zoo file and zoo kcl accept the same spellings, including the kg:m3 wire form.

Environment

Zoo CLI v0.2.184 (33534cd). Reviewed against the current main of KittyCAD/cli.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions