[discussion] packaging qmk

[superfell]

Having recently worked with qmk for keyboard firmware, I thought I'd take a stab at writing a package for it.
You can see the attempt here superfell@2e0adeb

qmk has a lot of dependencies. There are some base dependencies (git, python3) that are needed to get the qmk cli tool, and then that tool is used to set everything up including a long list of deb packages and more python packages.

when working with qmk, you work directly in the qmk_firmware tree, its not a separate library. qmk setup will clone the repo to the relevant location. I Used ~/w/qmk_firmware. but this seems wrong. But if its somewhere else and added to the provides, then that also seems wrong.

perhaps qmk isn't a tool and so isn't a good fit for cubicle? Or perhaps there some secret way of using qmk without your work being in the qmk_firmware tree.

[ongardie]

BTW, GitHub seems to have "Discussions" now: https://github.com/ongardie/cubicle/discussions

I'm not familiar with qmk but just poked around with it a little.

You should be able to depend on pypi.qmk to get that tool installed with Cubicle's python and pypi packages. I think it worked for me. Or equivalently in TOML:

[depends.pypi]
qmk = {}

So as a first step, I think it makes sense to define a qmk package that has that dependency and the Debian-level dependencies, so that you can just depend on that and run qmk setup without doing more stuff.

I didn't really pay close enough attention to see if more things need to be pipped for development or if it's only the installation of the qmk tool that's needed.

Then qmk setup seems to go off and clone a bunch of repos, and you're right, that's awkward to package. If they expect you to go develop in those repos directly, then I think that belongs in the work dir of the end container, not packaged.

[ongardie]

Oh, also, you can put your package here ~/.local/share/cubicle/packages/00local/qmk and Cubicle should find it. You don't need to define all your packages in the Cubicle source tree. You can override built-in packages that way, too (for example to include your own configs).