ZMK CLI

[innovaker]

• A CLI tool that serves as the main point of entry for most users.
• Probably written in Python and published as zmk.
• Wraps up git, west and other tooling.
  • Similar to how west wraps around git, cmake, ninja, etc.
• Encapsulates multiplatform support.
• Provides sanity checks on parameters.
  • e.g. checks the board, shield, keymap etc. and invalid combinations of them.
• Provides rudimentary error handling.
  • Provides useful feedback for common errors.
  • Points users to ZMK help for unexpected errors.
• Perhaps provides an interactive prompt/menu for commands and parameters.
• Perhaps caches parameters.
• Perhaps wrap flashing as well?
• Perhaps setting up dev environments?

From:

• https://discord.com/channels/719497620560543766/719565084208398406/720010131613417493
• https://discord.com/channels/719497620560543766/719565084208398406/720016130554462290
• https://discord.com/channels/719497620560543766/719565084208398406/721331753393848451
• https://discord.com/channels/719497620560543766/719565084208398406/721462710356672602

[innovaker]

Should build upon multiplatform exploration started by #12 and #26.

[innovaker]

@petejohanson, would we still like to proceed with this idea - not as a replacement for setup.sh - but as a development tool?

If so, then let's add it to Hacktoberfest.

[petejohanson]

I'm kind of on the fence here. To a certain degree, this "hides" west, but only so well. I would rather consider what we really want to get from such a tool before we suggest it fora newcomer. Having someone spend a bunch of time on something, that we then say "Nah, that's not what we want!" really would stink.

[okke-formsma]

I have set up one west command (west test) as a proof of concept; https://github.com/zmkfirmware/zmk/pull/385

[caksoylar]

For reference, @joelspadin developed https://github.com/joelspadin/zmk-setup-script that currently encapsulates the user setup script in a Python-based CLI that uses an extensible zmk module.

[joelspadin]

After using QMK again recently, I was thinking of borrowing some ideas from that, such as having a command such as zmk install which creates a config repo and remembers where it is, and then all further commands run from anywhere will operate on that repo unless otherwise specified.

That setup script might then be split across zmk install and zmk add-keyboard commands, with zmk being a script you can pip install.

[joelspadin]

https://github.com/joelspadin/zmk-cli is an attempt to do this. It currently handles

• Walking you through creating a config repo and cloning it to your PC
• Copying stock keymaps for keyboards into the config repo
• Opening keymaps in a text editor
• Adding/removing keyboards from the GitHub build
• Opening a browser to the GitHub actions page
• Adding/removing Zephyr modules
• Creating new boards/shields from a template (limited number of templates currently, but we can expand this later)

It does not currently handle flashing keyboards, but that could potentially be implemented.

It intentionally does not handle building the firmware or setting up a dev environment. I currently consider that out of scope for what this tool is intended to do, but if enough people want that, we could try adding it.

[Townk]

I wish I knew about this project before I created my zmk-cli. Although yours and mine are dealing with different things, the fact that yours will become part of the ZMK docs, will force me to think on a different name.

Any plans to have the tool dealing with local build setup? I would be happy to archive my thing if your tool can handle that part.

[joelspadin]

Setting up local builds isn't currently an area I've been focused on. My primary goal was to make a tool to replace the separate bash and PowerShell setup scripts, but I'm not opposed to adding more subcommands to handle common tasks for local builds.

What particular parts of setting up a local build do you find difficult? Just running a local build that matches the GitHub build?

[Townk]

What particular parts of setting up a local build do you find difficult? Just running a local build that matches the GitHub build?

It’s not difficult, it’s tedious and whenever you have to do some special thing for the build, you then have to replicate that on your build.yaml so your GA can work as your local. Anyway, this PR is not about that, I’ll continue the discussion in the tool’s repo.