Do we actually need a “packages” field?

Do we actually need a “packages” field?

[Ricardo Wurmus]

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

Re: Do we actually need a “packages” field?

[zimoun]

Hi Ricardo,

On Sun, 2 Feb 2020 at 11:39, Ricardo Wurmus <rekado@elephly.net> wrote:

> What do you think?

Well, considering Mercurial, does it become?

-8<---------------cut here---------------start------------->8---
process: fetch-data
[...]
  #{mercurial}/bin/hg clone {{inputs}} {{outputs}}
--8<---------------cut here---------------end--------------->8---

I am not sure it is more readable.
Moreover the user has to know the path.

Even I am not sure to understand why you want to change, from my
opinion, and based on my user experience, it does not matter where I
have to provide the package name but the issue is to find the name of
the package (and the module even if specification->package and related
help).


Cheers,
simon

Re: Do we actually need a “packages” field?

[Ricardo Wurmus]

zimoun <zimon.toutoune@gmail.com> writes:

> Well, considering Mercurial, does it become?
>
> -8<---------------cut here---------------start------------->8---
> process: fetch-data
> [...]
>   #{mercurial}/bin/hg clone {{inputs}} {{outputs}}
> --8<---------------cut here---------------end--------------->8---
>
> I am not sure it is more readable.
> Moreover the user has to know the path.

Yes.

> Even I am not sure to understand why you want to change, from my
> opinion, and based on my user experience, it does not matter where I
> have to provide the package name but the issue is to find the name of
> the package (and the module even if specification->package and related
> help).

Yeah, I agree.  I don’t *want* to change it as I think it looks clearer
the way it is now.

I was just exploring that path and by the time I finished writing the
email I decided to just ask for input and not waste the description of
my thoughts :)

--
Ricardo