From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:58578) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLkG6-00070Y-Tt for guix-patches@gnu.org; Tue, 07 Apr 2020 05:11:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jLkG5-0005sI-VN for guix-patches@gnu.org; Tue, 07 Apr 2020 05:11:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:38008) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jLkG5-0005s4-Rb for guix-patches@gnu.org; Tue, 07 Apr 2020 05:11:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jLkG5-0002c8-Ki for guix-patches@gnu.org; Tue, 07 Apr 2020 05:11:01 -0400 Subject: [bug#40373] [PATCH] guix: new command "guix run-script" Resent-Message-ID: From: Konrad Hinsen In-Reply-To: <87mu7slwwh.fsf@gnu.org> References: <875zeiudjm.fsf@gnu.org> <87mu7slwwh.fsf@gnu.org> Date: Tue, 07 Apr 2020 11:10:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 40373@debbugs.gnu.org Hi Ludo, >> I am of course aware that much of the code in "run-script" is the same >> as in "repl", which is not good. > > Yes, we can probably factorize a bit. We must make sure =E2=80=98-q=E2= =80=99 is not > implemented by this command; =E2=80=98-t=E2=80=99 is also useless. Right. > We do have that with =E2=80=98%standard-build-options=E2=80=99, for insta= nce, although > not as nicely-structured as we=E2=80=99d like (in general, I=E2=80=99d pr= efer to have a > GNU argp-style command-line API than what we have). It would also be nice to share the documentation for these options among different scripts. That's actually more lines of code than the code itself. More generally, it would be nice to decouple implementation decisions from user interface decisions. Git provides a nice example of what happens when user interface design follows ease of implementation criteria for a while. It's probably the most hated essential piece of software by now. >From a user interface point of view, it is preferable to have many commands with clear names, rather than few commands overloaded with multiple functions selected by cryptic options. Cheers, Konrad