[bug#39086] [PATCH 2/5] gnu: Add unicode-emoji.

[Leo Prikler <leo.prikler@student.tugraz.at>]

Hi Ricardo,

Am Donnerstag, den 16.01.2020, 22:04 +0100 schrieb Ricardo Wurmus:
> Hi Leo,
> 
> > * gnu/packages/ibus.scm (unicode-emoji): New package.
> 
> Thank you for these patches!
> 
> > +(define-public unicode-emoji
> > +  (package
> > +    (name "unicode-emoji")
> > +    (version "12.0")
> > +    (source #f)
> 
> It’s pretty unusual to not provide a source.  This will also make
> “guix
> build -S unicode-emoji” turn up nothing.  It may be a good idea to
> elevate at least one of the inputs to “source” status.
> 
> Ideally, all of the inputs would be considered sources like we’re
> doing
> it for texlive-* packages.  It’s a pity that we can’t express
> multiple
> URLs for the url-fetch method.
I'm somewhat confused by this comment.  While some of the texlive
packages do have actual sources, the big ones (texlive, texlive-union,
...) don't.  I know that computed-origin is a thing that exists, but
this would really have been overkill for me.

> > +    (build-system trivial-build-system)
> > +    (arguments
> > +     `(#:modules ((guix build utils))
> > +       #:builder
> > +       (let ((out (string-append %output "/share/unicode/emoji")))
> > +         (use-modules (guix build utils))
> > +         (mkdir-p out)
> > +         (for-each
> > +          (lambda (input)
> > +            (copy-file
> > +             (cdr input)
> > +             (string-append out "/"
> > +                            (substring (car input) 8) ; strip
> > "unicode-"
> > +                            ".txt")))
> 
> We don’t like to use CAR and CDR, because they feel so 80s… :) We
> prefer
> to use MATCH instead, because that feels more like the 90s.  You
> could
> also use MATCH-LAMBDA.
Will do.

> Using a magical 8 also doesn’t feel right.  You only need to strip
> the
> “unicode-” prefix because you chose to use it in the labels of these
> inputs.  I don’t know… I feel that there’s a prettier way to express
> this, but perhaps there’s no *shorter* way.
The thing is, I kinda do need those prefixes, because otherwise those
files will be stored as gnu/store/<hash>-emoji-<whatever>.txt, which
feels wrong.  AFAIK Guile has no string-remove-prefix.

> > +    (inputs
> > +     `(("unicode-emoji-data"
> > +        ,(origin
> > +           (method url-fetch)
> > +           (uri "
> > https://www.unicode.org/Public/emoji/12.0/emoji-data.txt")
> > +           (sha256
> > +            (base32
> > "03sf7h1d6kb9m5s02lif88jsi5kjszpkfvcymaqxj8ds70ar9pgv"))))
> > +       ("unicode-emoji-sequences"
> > +        ,(origin
> > +           (method url-fetch)
> > +           (uri "
> > https://www.unicode.org/Public/emoji/12.0/emoji-sequences.txt")
> > +           (sha256
> > +            (base32
> > "1hghki2rn3n7m4lwpwi2a5wrsf2nij4bxga9ldabx4g0g2k23svs"))))
> > +       ("unicode-emoji-test"
> > +        ,(origin
> > +           (method url-fetch)
> > +           (uri "
> > https://www.unicode.org/Public/emoji/12.0/emoji-test.txt")
> > +           (sha256
> > +            (base32
> > "1dqd0fh999mh6naj816ni113m9dimfy3ih9nffjq2lrv9mmlgdck"))))
> > +       ("unicode-emoji-variation-sequences"
> > +        ,(origin
> > +           (method url-fetch)
> > +           (uri "
> > https://www.unicode.org/Public/emoji/12.0/emoji-variation-sequences.txt
> > ")
> > +           (sha256
> > +            (base32
> > "1cccwx5bl79w4c19vi5dhjqxrph92s8hihp9y8s2cqvdzmgbln7a"))))
> > +       ("unicode-emoji-zwj-sequences"
> > +        ,(origin
> > +           (method url-fetch)
> > +           (uri "
> > https://www.unicode.org/Public/emoji/12.0/emoji-zwj-sequences.txt")
> > +           (sha256
> > +            (base32
> > "1l791nbijmmhwa7kmvfn8gp26ban512l6mgqpz1mnbq3xm19181n"))))))
> 
> Please use the version string from above in the URLs here.  It’s just
> a
> little less to update when upgrading the package in the future.
Will do.

> > +    (description
> > +     "Data files for the Unicode Technological Standard #51
> > (Emoji).")
> 
> Please use a complete sentence here.
I doubt the nature of this package will allow me to be more
descriptive, but I'll try.

Regards, Leo