unofficial mirror of
 help / color / mirror / Atom feed
From: Ricardo Wurmus <>
Subject: Do we actually need a “packages” field?
Date: Sun, 02 Feb 2020 11:38:57 +0100
Message-ID: <> (raw)


consider this example:

--8<---------------cut here---------------start------------->8---
process: compress-file
  packages "gzip"
  inputs "/tmp/file.txt"
  outputs "/tmp/file.txt.gz"
      space 20 mebibytes
      time   2 minutes
  # { gzip {{inputs}} -c > {{outputs}} }
--8<---------------cut here---------------end--------------->8---

“gzip” is listed twice: once as a package in the “packages” field and
once again as an executable in the expression at the bottom.  The “gzip”
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’m 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’d 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’s why I added support for package specification

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’s an environment that contains the “gzip” package.  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 “packages” field.  I haven’t
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"
      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’t much to be gained from
embedding packages in process expressions.

What do you think?


             reply	other threads:[~2020-02-02 10:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-02 10:38 Ricardo Wurmus [this message]
2020-02-02 12:06 ` zimoun
2020-02-02 12:39   ` Ricardo Wurmus

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:

  List information:

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

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

unofficial mirror of

This inbox may be cloned and mirrored by anyone:

	git clone --mirror gwl/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 gwl gwl/ \
	public-inbox-index gwl

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone