From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:47924) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iyCeg-0000c5-F8 for gwl-devel@gnu.org; Sun, 02 Feb 2020 05:39:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iyCee-0001Cx-G4 for gwl-devel@gnu.org; Sun, 02 Feb 2020 05:39:05 -0500 Received: from sender4-of-o51.zoho.com ([136.143.188.51]:21179) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iyCee-0001Bo-3l for gwl-devel@gnu.org; Sun, 02 Feb 2020 05:39:04 -0500 From: Ricardo Wurmus Subject: =?UTF-8?B?RG8gd2UgYWN0dWFsbHkgbmVlZCBhIOKAnHBhY2thZ2Vz4oCdIGZp?= =?UTF-8?B?ZWxkPw==?= Date: Sun, 02 Feb 2020 11:38:57 +0100 Message-ID: <87zhe1s27y.fsf@elephly.net> 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: gwl-devel-bounces+kyle=kyleam.com@gnu.org Sender: "gwl-devel" To: gwl-devel@gnu.org Hi, consider this example: --8<---------------cut here---------------start------------->8--- process: compress-file packages "gzip" inputs "/tmp/file.txt" outputs "/tmp/file.txt.gz" run-time complexity space 20 mebibytes time 2 minutes # { gzip {{inputs}} -c > {{outputs}} } --8<---------------cut here---------------end--------------->8--- =E2=80=9Cgzip=E2=80=9D is listed twice: once as a package in the =E2=80=9Cp= ackages=E2=80=9D field and once again as an executable in the expression at the bottom. The =E2=80=9C= gzip=E2=80=9D in the expression at the bottom is just text. The thing at the bottom is not a G-expression. It could be, but it is not. One of the reasons why I=E2=80=99m not comfortable with exposing G-expressions to authors of workflows is that this would also expose Guix as a library to the users as they=E2=80=99d have to know what modules provide what packages. We Guix contributors regularly move packages to different modules as needed, between releases, without any guarantees of stability. That=E2=80=99s why I added support for package specification strings. This decision had the unfortunate side-effect of separating the expression from its meaning. When the expression is evaluated it is done in an environment that the process definition specifies. In this case it=E2=80=99s an environment that contains the =E2=80=9Cgzip=E2=80=9D p= ackage. Placed in a different environment the expression might mean something else. We could introduce something very much like that package splicing feature of G-expressions and get rid of the =E2=80=9Cpackages=E2=80=9D fiel= d. I haven=E2=80=99t thought of the syntax yet, but consider this instead: --8<---------------cut here---------------start------------->8--- process: compress-file inputs "/tmp/file.txt" outputs "/tmp/file.txt.gz" run-time complexity space 20 mebibytes time 2 minutes #{gzip}/bin/gzip {{inputs}} -c > {{outputs}} --8<---------------cut here---------------end--------------->8--- I wonder: would this be any better? If so, would it still be better in bigger, more complicated expressions? I think it might not be worth the effort. Keeping all packages in a simple list is easy to understand and there isn=E2=80=99t much to be gained= from embedding packages in process expressions. What do you think? -- Ricardo