[bug#45954] Telegram-CLI (v7)

[Leo Prikler]

Am Montag, den 01.02.2021, 17:08 -0500 schrieb Raghav Gururajan:
> +(define-public telegram-cli
> +  (let ((commit "6547c0b21b977b327b3c5e8142963f4bc246187a")
> +        (revision "324"))
> +    (package
> +      (name "telegram-cli")
> +      (version
> +       (git-version "1.3.1" revision commit))
I didn't notice this before, but is there a reason to package this
version over 1.3.1?

> (getenv "TEMP")
Please stop trying to use this as a snippet to mean "the root of the
source and build directory".  It is extremely obscure and people are
already using "../source" just fine.  (Just do an rgrep if you aren't
convinced.)

> > You might want to write that in terms of copy-build-system.
> 
> Hmm. I tried but couldn't come up with a way to do it like that. :(
You can still try harder for v8 ;)

> The script may only be used on foreign-distro for now. For guix
> system, 
> we need to define a service for it.
> 
> Also, running telegram-cli doesn't require daemon, but vice-versa.
> The 
> daemon is intended to be a complimentary feature to run telegram-cli
> on 
> headless server.
In that case, does the daemon script have any value of its own?  Given
that the latest release of telegram-cli is about six years old, I doubt
there is – foreign distros should already have it in their repos and
Guix as a package manager makes no claim to manage system stuff like
services on foreign distros.

> The file is a run-time script.
That means literally nothing.  The wrap phase exists for a reason, some
programs and script are even wrapped twice.

> Using (getenv "PATH") will instead use the value of PATH inside the
> build environment.
So you'll inadvertently have some native-inputs in it, is what you're
trying to say?  Of course, there are better ways of wrapping PATH, but
in this case wouldn't it be wise to limit it to just the expected
paths?  Again, assuming that there is even merit in shipping this file,
which is yet to be proven.

Regards,
Leo