From: Konrad Hinsen <konrad.hinsen@fastmail.net>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 40373@debbugs.gnu.org
Subject: [bug#40373] [PATCH] guix: new command "guix run-script"
Date: Thu, 02 Apr 2020 09:13:23 +0200 [thread overview]
Message-ID: <m1a73umkbw.fsf@khs-macbook.home> (raw)
In-Reply-To: <875zeiudjm.fsf@gnu.org>
Hi Ludo,
> What about making that just a new ‘-s’ flag for ‘guix repl’ (just like
> Guile’s ‘-s’ flag)? ‘-q’ should always be implied when doing that.
>
> Now, this wouldn’t be usable as a shebang due to the fact that only one
> argument is allowed, unless we do some extra argument tokenizing.
That is one reason why I opted for a separate command.
The other is that I am in tutorial-driven development mode: I need "guix
run-script" in order to be able to insert my own scripts (for analyzing
dependencies) into a Guix tutorial for an upcoming MOOC. So I need to
make sure that people can run my scripts easily, but also that they
understand what they are doing. A command that does something else than
its name suggests, with a similarity that is only visible to experts,
is no good for use in a tutorial.
BTW, I opted for a lengthy name ("run-script" rather than just "run" or
"script") according to the principle that short words should be left for
frequently used concepts (a principle respected by human languages, but
also by Lisp tradition).
I am of course aware that much of the code in "run-script" is the same
as in "repl", which is not good. But I'd rather think about a better
framework for code sharing among Guix scripts than about pushing too
much semantic differences into obscure options. An example would be
reusable "option clusters", such as "options for Guile" or "options for
channels".
Cheers,
Konrad.
next prev parent reply other threads:[~2020-04-02 7:14 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 14:09 [bug#40373] [PATCH] guix: new command "guix run-script" Konrad Hinsen
2020-04-01 21:00 ` Ludovic Courtès
2020-04-02 7:13 ` Konrad Hinsen [this message]
2020-04-02 9:17 ` zimoun
2020-04-02 9:37 ` Konrad Hinsen
2020-04-03 9:17 ` Konrad Hinsen
2020-04-03 9:48 ` Ludovic Courtès
2020-04-03 9:19 ` [bug#40373] [PATCH] guix: new command "guix run" generalizes "guix repl" Konrad Hinsen
2020-04-03 9:51 ` [bug#40373] [PATCH] guix: new command "guix run-script" Ludovic Courtès
2020-04-07 9:10 ` Konrad Hinsen
2020-04-07 10:36 ` Ludovic Courtès
2020-04-17 11:21 ` zimoun
2020-04-23 10:12 ` Konrad Hinsen
2020-04-23 14:41 ` zimoun
2020-04-29 16:04 ` Konrad Hinsen
2020-04-30 12:42 ` zimoun
2020-05-04 13:54 ` Konrad Hinsen
2020-05-04 17:48 ` zimoun
2020-05-14 9:29 ` Konrad Hinsen
2020-05-14 9:44 ` bug#40373: " zimoun
2020-04-02 9:08 ` [bug#40373] " zimoun
2020-04-02 9:21 ` Konrad Hinsen
2020-04-02 9:25 ` Konrad Hinsen
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1a73umkbw.fsf@khs-macbook.home \
--to=konrad.hinsen@fastmail.net \
--cc=40373@debbugs.gnu.org \
--cc=ludo@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).