Do we actually need a “packages” field?

[Ricardo Wurmus <rekado@elephly.net>]

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---

“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
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’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"
  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’t much to be gained from
embedding packages in process expressions.

What do you think?

--
Ricardo