Crux doctor

[StuartHarris]

CLI tool

Some ideas for a simple Crux CLI that can analyze, validate, fix, and create Crux projects within a workspace. Let's start simple, and evolve over time.

Some ideas:

crux doctor
# Lists files not matching templates

crux doctor diff [file]
# Shows the diff between file and template

crux doctor fix [file]
# Replaces file with template

crux doctor fix --missing
# Adds files which are wholy missing compared with the template

crux init
# Creates a Crux.toml file with the basic configuration - a single core and type-gen crate
# Runs `crux doctor fix --missing`

crux new [path]
# Same as `init` but in a specified directory

crux add --shell [name] [template] --cores [core_a core_b ...]
# Adds the configuration into crux.toml
# Runs `crux doctor fix --missing`

To do list

• Doctor
  • [x] Parse, validate, rewrite Crux.toml
  • [ ] Fill in the core template correctly
    • [ ] Fill in core name
  • [ ] Fill in the shell template correctly
    • [ ] Choose the right template file(s) (e.g. iOS)
    • [ ] Fill in the shell name (in the right format, e.g. camel case)
    • [ ] Fill in the relevant core linking configuration for each linked core
  • [ ] Diff reality vs template "ideal"
    • [ ] Display full diff
    • [ ] Display diff --paths-only
    • [ ] Display diff for a specific file (or path prefix?)
  • [ ] fix - Replace file with template generated file
• init / new / add
  • [ ] Edit the Crux.toml
• Later?
  • [ ] Interactive doctor

[wasnotrice]

Could this CLI also help "install" capabilities? It would be cool if there were a convention for packaging up "default" shell implementations in capability crates.

crux add --cap [name] --shell [name]
# Copies the default shell implementation for [cap] into [shell]

[StuartHarris]

Yep, love it! The next thing we want to do is to refactor the examples a bit more so that all the "boilerplate" code is in its own files — this is partially done already, but needs a bit more love — so that the diffs make more sense. Then the shell-side code for the capabilities, which is very much generic, can be added, analysed, and fixed in the same way. And we can have the relevant subcommands/flags on the cli as you suggest.

[charypar]

Distributing those implementations is definitely the plan @wasnotrice, but we're hoping to allow them to be distributed in "fat crates" if you will, so no additional tooling is required... but we're not yet sure exactly how that might work.

We'll need a pattern for how that code is found and linked into the shells, so that we can then help verify all that with the doctor like Stu is suggesting