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.
value_enumis a silent no-op on everykcmc-typed unit flag (no possible-values, cryptic errors), andzoo filevszoo kclaccept different density unit spellingsContext: 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 volumeonly).1.
value_enumdoes nothing onkcmc-typed flagsMany unit and format flags carry
#[clap(..., value_enum)]but are typed withkcmc::units::*(orkcmc::ImageFormat/FileImportFormat). Thekittycad-modeling-cmdscrate has no clap dependency, so those types do not implementclap::ValueEnum. With current clap this does not fail to compile:value_parser!falls back toFromStrand thevalue_enumattribute silently does nothing. So--helpprints no possible values, an invalid value prints onlyerror: 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-boxunit flags.src/cmd_file.rs:file snapshot --src-format,--output-format.By contrast the
kittycad::types::*flags on thezoo file volume/mass/densityside really deriveclap::ValueEnum(thekittycadcrate is built with itsclapfeature), so their--helplists values and their errors enumerate the alternatives.2. Density unit spelling diverges between
fileandkclzoo file mass|density --material-density-unit(typekittycad::types::UnitDensity) accepts only the kebab spellingslb-ft3/kg-m3.zoo kcl mass|density --material-density-unit(typekcmc::units::UnitDensity, hand-writtenFromStr) acceptslbft3 | lb:ft3 | lb-ft3andkgm3 | kg:m3 | kg-m3.kg:m3is also the serde/API wire spelling, so thefileside rejects the very string the API returns in its own JSON.Concrete failure
zoo kcl surface-area --helpshows--output-unit <OUTPUT_UNIT>with no value list, andzoo kcl mass ... --material-density-unit kgm2prints onlyparse failedwith no hint thatkg:m3/lb:ft3are valid. A script that computes mass viazoo kcl mass --material-density-unit kg:m3then switches to a STEP input withzoo file massand the same flag breaks withinvalid value 'kg:m3'.Verify
Compare
zoo kcl surface-area --help(no possible values) withzoo file surface-area --help(lists them). Runzoo file mass --material-density-unit kg:m3 ...(rejected) versuszoo kcl mass --material-density-unit kg:m3 ...(accepted at parse).Suggested fix
Implement or derive
clap::ValueEnumfor thekcmcunit/format enums (or wrap them in local enums that do), and unify the density (and other) unit enums sozoo fileandzoo kclaccept the same spellings, including thekg:m3wire form.Environment
Zoo CLI v0.2.184 (33534cd). Reviewed against the current
mainof KittyCAD/cli.