[bug#42682,2/2] gnu: Add qmk-cli.

* gnu/packages/hardware.scm (qmk-cli): New variable.
---
 gnu/packages/hardware.scm | 50 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

> +    (propagated-inputs
> +     `(("arm-none-eabi-gcc" ,gcc-arm-none-eabi-7-2018-q2-update)
> +       ("avr-gcc" ,avr-toolchain-5)
> +       ("avrdude" ,avrdude)
> +       ("dfu-programmer" ,dfu-programmer)
> +       ("dfu-util" ,dfu-util)
> +       ("git" ,git)
> +       ("python3" ,python)
> +       ("python-appdirs" ,python-appdirs)
> +       ("python-argcomplete" ,python-argcomplete)
> +       ("python-colorama" ,python-colorama)
> +       ("python-flake8" ,python-flake8)
> +       ("python-hjson" ,python-hjson)
> +       ("python-nose2" ,python-nose2)
> +       ("python-yapf" ,python-yapf)))

Do we really need to propagate all those inputs? Can't we hardcode the
path to those tools directly in the sources, if they are not registered at
build time?

> +    (arguments
> +     `(#:phases (modify-phases %standard-phases
> +                  (add-before 'check 'set-qmk-home
> +                    (lambda _
> +                      ;; tests fail without this variable set
> +                      (setenv "QMK_HOME"
> +                              "")

Who is supposed to set it otherwise?

> +     "A program to help users work with QMK Firmware.")

You also need to elaborate here :)

Thanks,

Mathieu

Dnia 2020-08-03, o godz. 10:26:03
Mathieu Othacehe <othacehe@gnu.org> napisał(a):

> 
> > +    (propagated-inputs
> > +     `(("arm-none-eabi-gcc" ,gcc-arm-none-eabi-7-2018-q2-update)
> > +       ("avr-gcc" ,avr-toolchain-5)
> > +       ("avrdude" ,avrdude)
> > +       ("dfu-programmer" ,dfu-programmer)
> > +       ("dfu-util" ,dfu-util)
> > +       ("git" ,git)
> > +       ("python3" ,python)
> > +       ("python-appdirs" ,python-appdirs)
> > +       ("python-argcomplete" ,python-argcomplete)
> > +       ("python-colorama" ,python-colorama)
> > +       ("python-flake8" ,python-flake8)
> > +       ("python-hjson" ,python-hjson)
> > +       ("python-nose2" ,python-nose2)
> > +       ("python-yapf" ,python-yapf)))
> 
> Do we really need to propagate all those inputs?
The python dependencies were added to propagated inputs automatically
by "guix import". The other tools are needed in the user profine,
because qmk-cli uses them, for example it fetches qmk firmware from
git, it runs some *python stuff* and when user is done making changes
to their firmware, qmk cli builds the firmware using the compiler and
flashes it using dfu.

I think it would be cool if Guix allowed defining profiles and
environments the same way it allows defining packages.
This way installing qmk-cli would also install say qmk-profile with all
headers (and tools) needed for development. Now, even though
arv-toolchain is installed, I have to run "guix environment qmk-cli" to
be able to work with the firmware without getting build errors.

> Can't we hardcode the
> path to those tools directly in the sources, if they are not
> registered at build time?
I need them installed, so qmk-cli doesn't complain. Should the user be
responsible for installing all the tools needed for development?

> > +    (arguments
> > +     `(#:phases (modify-phases %standard-phases
> > +                  (add-before 'check 'set-qmk-home
> > +                    (lambda _
> > +                      ;; tests fail without this variable set
> > +                      (setenv "QMK_HOME"
> > +                              "")
> 
> Who is supposed to set it otherwise?
I'm not sure. That's the first thing qmk-cli sets when it is already
installed. Normally, qmk-cli is installed by pip, maybe it is
responsible for setting the variables?

> > +     "A program to help users work with QMK Firmware.")
> 
> You also need to elaborate here :)
Should I describe what qmk firmware is or say more about what working
with qmk firmware is, or both?

> Thanks,
> 
> Mathieu

Hello Jan,

>> Do we really need to propagate all those inputs?
> The python dependencies were added to propagated inputs automatically
> by "guix import". The other tools are needed in the user profine,
> because qmk-cli uses them, for example it fetches qmk firmware from
> git, it runs some *python stuff* and when user is done making changes
> to their firmware, qmk cli builds the firmware using the compiler and
> flashes it using dfu.

Turns out qmk_cli is just a wrapper around qmk_firmware. It clones qmk
firmware repository because it cannot locate a qmk_firmware directory
using QMK_HOME variable.

I think the proper way to do things would be to package qmk_firwmare
first (it has a root shell.nix file that should help). Then this package
would define QMK_HOME using "search-paths".

This way, qmk_cli would just require some python libraries, but would
not propagate git, and the toolchains.

Does it make sense?

Thanks,

Mathieu

Dnia 2020-08-05, o godz. 11:17:43
Mathieu Othacehe <othacehe@gnu.org> napisał(a):

> 
> Hello Jan,
> 
> >> Do we really need to propagate all those inputs?
> > The python dependencies were added to propagated inputs
> > automatically by "guix import". The other tools are needed in the
> > user profine, because qmk-cli uses them, for example it fetches qmk
> > firmware from git, it runs some *python stuff* and when user is
> > done making changes to their firmware, qmk cli builds the firmware
> > using the compiler and flashes it using dfu.
> 
> Turns out qmk_cli is just a wrapper around qmk_firmware. It clones qmk
> firmware repository because it cannot locate a qmk_firmware directory
> using QMK_HOME variable.
> 
> I think the proper way to do things would be to package qmk_firwmare
> first (it has a root shell.nix file that should help). Then this
> package would define QMK_HOME using "search-paths".
> 
> This way, qmk_cli would just require some python libraries, but would
> not propagate git, and the toolchains.
> 
> Does it make sense?

But the entire point of qmk firmware is that the user configures it. I
had to modify the source code to make my keyboard work and add some
extra features like layouts, special keys. Your solution will only work
for the unmodified and default firmware, or is there a Guix solution
for it I'm not aware of, like a convenient interface for user defined
packages?

> Thanks,
> 
> Mathieu

Hello,

> But the entire point of qmk firmware is that the user configures it. I
> had to modify the source code to make my keyboard work and add some
> extra features like layouts, special keys. Your solution will only work
> for the unmodified and default firmware, or is there a Guix solution
> for it I'm not aware of, like a convenient interface for user defined
> packages?

Oh I see. Nonetheless, qmk_cli is a thin wrapper around qmk_firmware. I
think it would make more sense to have qmk_firmware properly packaged.

This way we would offer people a way to build their customized firmware
without propagating toolchains and fetching a git repository.

WDYT?

Mathieu

Dnia 2020-08-07, o godz. 10:20:17
Mathieu Othacehe <othacehe@gnu.org> napisał(a):

> 
> Hello,
> 
> > But the entire point of qmk firmware is that the user configures
> > it. I had to modify the source code to make my keyboard work and
> > add some extra features like layouts, special keys. Your solution
> > will only work for the unmodified and default firmware, or is there
> > a Guix solution for it I'm not aware of, like a convenient
> > interface for user defined packages?
> 
> Oh I see. Nonetheless, qmk_cli is a thin wrapper around qmk_firmware.
> I think it would make more sense to have qmk_firmware properly
> packaged.
> 
> This way we would offer people a way to build their customized
> firmware without propagating toolchains and fetching a git repository.
> 
> WDYT?
I can do this then, give me some time.

> Mathieu


Jan Wielkiewicz

Jan Wielkiewicz <tona_kosmicznego_smiecia@interia.pl> writes:

> Dnia 2020-08-07, o godz. 10:20:17
> Mathieu Othacehe <othacehe@gnu.org> napisał(a):
>
>> 
>> Hello,
>> 
>> > But the entire point of qmk firmware is that the user configures
>> > it. I had to modify the source code to make my keyboard work and
>> > add some extra features like layouts, special keys. Your solution
>> > will only work for the unmodified and default firmware, or is there
>> > a Guix solution for it I'm not aware of, like a convenient
>> > interface for user defined packages?
>> 
>> Oh I see. Nonetheless, qmk_cli is a thin wrapper around qmk_firmware.
>> I think it would make more sense to have qmk_firmware properly
>> packaged.
>> 
>> This way we would offer people a way to build their customized
>> firmware without propagating toolchains and fetching a git repository.
>> 
>> WDYT?
> I can do this then, give me some time.
>
>> Mathieu
>
>
> Jan Wielkiewicz

Hi Jan, have you been working on this?  My new qmk-supported keyboard is
coming and I'd love to be able to flash it with guix.

I built qmk-firmware in guix (but there are bundled dependencies that
still need to be removed).

I was planning to use mugur with it, which calls

make -C source-path keyboard:type

So, my first idea (which should apply to qmk-cli too) was to patch this
to call guix build --with-source and hopefully get this working, but I
don't know how robust this is (or if it is even going to work).

(I'll also have to package https://github.com/zsa/wally, but it does not
seem to require qmk-cli)

Nicolò

Dnia 2021-02-05, o godz. 12:39:55
Nicolò Balzarotti <anothersms@gmail.com> napisał(a):

> Hi Jan, have you been working on this?  My new qmk-supported keyboard
> is coming and I'd love to be able to flash it with guix.
Nope, I'm quite busy studying right now, will resume my work this
summer.

> I built qmk-firmware in guix (but there are bundled dependencies that
> still need to be removed).
> 
> I was planning to use mugur with it, which calls
> 
> make -C source-path keyboard:type
> 
> So, my first idea (which should apply to qmk-cli too) was to patch
> this to call guix build --with-source and hopefully get this working,
> but I don't know how robust this is (or if it is even going to work).
> 
> (I'll also have to package https://github.com/zsa/wally, but it does
> not seem to require qmk-cli)
> 
> Nicolò

I totally don't remember what the issue was about. If you have a
working package then go ahead.
Thanks for info anyway, I'll check it out later.

Jan Wielkiewicz

> I totally don't remember what the issue was about. If you have a
> working package then go ahead.
> Thanks for info anyway, I'll check it out later.

Ok, I'll send some patches in the following days :)

Thanks, Nicolo'