[bug#45190,1/1] gnu: Add pinentry-rofi.

* gnu/packages/gnupg.scm (pinentry-rofi): New variable.
---
 gnu/packages/gnupg.scm | 81 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 81 insertions(+)

Hi Fredrik,

Fredrik Salomonsson <plattfot@posteo.net> skribis:

> * gnu/packages/gnupg.scm (pinentry-rofi): New variable.

Overall LGTM, with some minor issues highlighted below:

> +(define-public pinentry-rofi
> +  (package
> +  (name "pinentry-rofi")

Indentation is off here (should be offset by two).

> +  (arguments
> +    `(#:strip-binaries? #f ;; Has no binaries and the strip phase is failing

Hmm the ‘strip’ phase should not fail.  Are you sure this is necessary?

> +      #:phases
> +      (modify-phases
> +        %standard-phases
> +        (add-after
> +          'install
> +          'hall-wrap-binaries

Nitpick: please indent as in other files.

> +          (lambda* (#:key inputs outputs #:allow-other-keys)
> +            (let* ((compiled-dir
> +                     (lambda (out version)
> +                       (string-append out "/lib/guile/" version "/site-ccache")))
> +                   (uncompiled-dir
> +                     (lambda (out version)
> +                       (string-append
> +                         out
> +                         "/share/guile/site"
> +                         (if (string-null? version) "" "/")
> +                         version)))
> +                   (dep-path
> +                     (lambda (env modules path)
> +                       (list env
> +                             ":"
> +                             'prefix
> +                             (cons modules
> +                                   (map (lambda (input)
> +                                          (string-append
> +                                            (assoc-ref inputs input)
> +                                            path))
> +                                        ,''("rofi"))))))
> +                   (out (assoc-ref outputs "out"))
> +                   (bin (string-append out "/bin/"))
> +                   (site (uncompiled-dir out "")))
> +              (match (scandir site)
> +                     (("." ".." version)
> +                      (for-each
> +                        (lambda (file)
> +                          (wrap-program
> +                            (string-append bin file)
> +                            (dep-path
> +                              "GUILE_LOAD_PATH"
> +                              (uncompiled-dir out version)
> +                              (uncompiled-dir "" version))
> +                            (dep-path
> +                              "GUILE_LOAD_COMPILED_PATH"
> +                              (compiled-dir out version)
> +                              (compiled-dir "" version))))
> +                        ,''("pinentry-rofi"))
> +                      #t))))))))

Since I think you’re also upstream :-), how about adding something like
that at the top of the installed executable:

  (eval-when (load expand eval)
    (set! %load-path (cons "@moddir@" %load-path))
    (set! %laod-compiled-path (cons "@godir@" %load-compiled-path)))

?

> +  (propagated-inputs `(("rofi" ,rofi)))

It’s best to avoid propagating.  Perhaps you can replace the “rofi”
string in ‘pinentry-rofi’ by “/gnu/store/…/bin/rofi” in a post-install
phase?

> +  (synopsis "Rofi GUI for GnuPG's passphrase input")
> +  (description "Simple pinentry GUI using rofi that allows users to enter a
> +passphrase when required by @code{gpg} or other software.")

Please make it a full sentence.  Also, to give context, perhaps replace
“rofi” by “the Rofi application launcher”.

Could you send an updated patch?

Thanks in advance and sorry for the delay!

Ludo’.

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

>> +(define-public pinentry-rofi
>> +  (package
>> +  (name "pinentry-rofi")
>
> Indentation is off here (should be offset by two).

Fixed in v2.

>> +  (arguments
>> +    `(#:strip-binaries? #f ;; Has no binaries and the strip phase is failing
>
> Hmm the ‘strip’ phase should not fail.  Are you sure this is necessary?

It was failing with a warning as there are no binaries to strip. But
it's not an error so I removed this in v2.

>> +      #:phases
>> +      (modify-phases
>> +        %standard-phases
>> +        (add-after
>> +          'install
>> +          'hall-wrap-binaries
>
> Nitpick: please indent as in other files.

Fixed in v2.

> Since I think you’re also upstream :-), how about adding something like
> that at the top of the installed executable:
>
>   (eval-when (load expand eval)
>     (set! %load-path (cons "@moddir@" %load-path))
>     (set! %laod-compiled-path (cons "@godir@" %load-compiled-path)))
>
> ?

Yup, I'm upstream as well. I don't mind adding that, just need to know
what it solves :). I'm guessing that it removes the need to wrap the
executable, is that correct?

And are the "@moddir@" and "@godir@" expected to be expanded by
automake? I tested to just add it in the source code and automake did
nothing with them.

For now I left it out in v2 as I'm a bit unsure of it.

>> +  (propagated-inputs `(("rofi" ,rofi)))

> It’s best to avoid propagating.  Perhaps you can replace the “rofi”
> string in ‘pinentry-rofi’ by “/gnu/store/…/bin/rofi” in a post-install
> phase?

Is there a rule of thumb or something to know when to use propagating
inputs? I'm a bit confused when to use is it. Is it just when dealing
with libraries? What are the downsides of using propagating inputs?
Apologize if this is already mentioned in the manual. Only sections I
could find that mentions propagated inputs are section 5.2 and 8.2.1.

Anyway this is fixed in v2, I added the rofi's binary path to PATH for
the wrapper of pinentry-rofi. 

>> +  (synopsis "Rofi GUI for GnuPG's passphrase input")
>> +  (description "Simple pinentry GUI using rofi that allows users to enter a
>> +passphrase when required by @code{gpg} or other software.")
>
> Please make it a full sentence.  Also, to give context, perhaps replace
> “rofi” by “the Rofi application launcher”.

I fleshed out the description in v2, let me know if it sounds better.

> Could you send an updated patch?

All updates should be in PATCH v2

> Thanks in advance and sorry for the delay!

Thank you for reviewing my patch and no worries about the delay.

Hi,

Fredrik Salomonsson <plattfot@posteo.net> skribis:

>>> +  (arguments
>>> +    `(#:strip-binaries? #f ;; Has no binaries and the strip phase is failing
>>
>> Hmm the ‘strip’ phase should not fail.  Are you sure this is necessary?
>
> It was failing with a warning as there are no binaries to strip. But
> it's not an error so I removed this in v2.

Right, it’s just a warning, due to the fact that .go files are ELF but
the ‘strip’ command doesn’t know what to do with them.

>> Since I think you’re also upstream :-), how about adding something like
>> that at the top of the installed executable:
>>
>>   (eval-when (load expand eval)
>>     (set! %load-path (cons "@moddir@" %load-path))
>>     (set! %laod-compiled-path (cons "@godir@" %load-compiled-path)))
>>
>> ?
>
> Yup, I'm upstream as well. I don't mind adding that, just need to know
> what it solves :). I'm guessing that it removes the need to wrap the
> executable, is that correct?
>
> And are the "@moddir@" and "@godir@" expected to be expanded by
> automake? I tested to just add it in the source code and automake did
> nothing with them.

It’s replaced provided ‘configure.ac’ defines them and AC_SUBSTs them,
along these lines (here they have a longer name):

  https://notabug.org/guile-zstd/guile-zstd/src/master/configure.ac#L43

>> It’s best to avoid propagating.  Perhaps you can replace the “rofi”
>> string in ‘pinentry-rofi’ by “/gnu/store/…/bin/rofi” in a post-install
>> phase?
>
> Is there a rule of thumb or something to know when to use propagating
> inputs? I'm a bit confused when to use is it. Is it just when dealing
> with libraries? What are the downsides of using propagating inputs?
> Apologize if this is already mentioned in the manual. Only sections I
> could find that mentions propagated inputs are section 5.2 and 8.2.1.

In general, propagated inputs should be avoided as they “pollute” the
user’s profile (you install X and find yourself with X, Y, and Z).

The preferred method in situations like this is to patch the source so
it uses absolute file names for commands.

Thanks for sending an updated patch!

Ludo’.