all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Eric Bavier <ericbavier@centurylink.net>
Cc: 31395@debbugs.gnu.org
Subject: [bug#31395] [PATCH 2/2] gnu: Add snap.
Date: Thu, 10 May 2018 15:10:00 +0200	[thread overview]
Message-ID: <87y3grpsgn.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <20180509213625.5fa4db0a@centurylink.net> (Eric Bavier's message of "Wed, 9 May 2018 21:36:25 -0500")

Hello,

Eric Bavier <ericbavier@centurylink.net> writes:

> This package looks fun, thanks for working on it, I played with it for
> a while in my browser :)

Heh.

> Just a few comments:

Thank you for the review.

>> +       (uri (string-append
>> +             "https://github.com/jmoenig/Snap--Build-Your-Own-Blocks/archive/"
>> +             version ".tar.gz"))
>
> I think we're trying to stay away from Github's auto-generated tarballs
> now, because they are not guaranteed to remain the same over time.
>
> Unfortunately this project doesn't seem to upload its own release
> tarballs.  I would instead use a git checkout.

Version is a tag, therefore a commit, so I would think it should remain
identical over time. Besides a number of packages use this (e.g.,
audacity...)

Granted, I'm not well-versed in Github technology. Yet, using a git
checkout slightly complicates the package, and its subsequent updates,
so I'd rather only use it if absolutely necessary.

WDYT?

>> +           (mkdir-p share)
>> +           (with-directory-excursion root
>> +             (copy-recursively "." share))
>
> This could be simplified to '(copy-recursively root share)', and the
> mkdir-p can even be left out because copy-recursively will create it
> for you.

OK.

>> +           (let* ((bin (string-append out "/bin"))
>> +                  (script (string-append bin "/snap"))
>> +                  (bash (string-append (assoc-ref %build-inputs "bash")
>> +                                       "/bin/bash"))
>> +                  (xdg-open (string-append (assoc-ref %build-inputs "xdg-utils")
>> +                                           "/bin/xdg-open"))
>> +                  (snap (string-append share "/snap.html")))
>> +             (mkdir-p bin)
>> +             (call-with-output-file script
>> +               (lambda (port)
>> +                 (format port "#!~a\n~a '~a'" bash xdg-open snap)))
>
> You could maybe use '(which "sh")' and '(which xdg-open)'.  A
> matter of taste, I think.

So (which "sh") should be in the (format ...) call instead of the `bash'
binding above? This is shorter, indeed.

>> +    (native-inputs
>> +     `(("gzip" ,gzip)
>> +       ("tar" ,tar)
>> +       ("js-filesaver" ,js-filesaver)))
>
> js-filesave should go in "inputs", right?

Correct.

>> +    (inputs
>> +     `(("bash" ,bash-minimal)
>> +       ("xdg-utils" ,xdg-utils)))
>> +    (home-page "https://snap.berkeley.edu")
>> +    (synopsis "Visual, blocks based programming language inspired by Scratch")
>
> We can leave out "inspired by Scratch" in the synopsis.

OK.

>> +This package provides a @command{snap} executable calling @command{xdg-open}
>> +to open a the application in a web browser.")
>            ^
> s/a the/the/

OK.

Regards,

-- 
Nicolas Goaziou                                                0x80A93738

  reply	other threads:[~2018-05-10 13:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-09 21:44 [bug#31395] [PATCH 0/2] Add Snap! educational programming language Nicolas Goaziou
2018-05-09 21:46 ` [bug#31395] [PATCH 1/2] gnu: Add js-filesaver Nicolas Goaziou
2018-05-09 21:46   ` [bug#31395] [PATCH 2/2] gnu: Add snap Nicolas Goaziou
2018-05-10  2:36     ` Eric Bavier
2018-05-10 13:10       ` Nicolas Goaziou [this message]
2018-05-10 13:47         ` Eric Bavier
2018-05-10 15:58           ` Nicolas Goaziou
2018-05-11  2:32             ` Eric Bavier
2018-05-11  8:46               ` bug#31395: " Nicolas Goaziou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y3grpsgn.fsf@nicolasgoaziou.fr \
    --to=mail@nicolasgoaziou.fr \
    --cc=31395@debbugs.gnu.org \
    --cc=ericbavier@centurylink.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.