unofficial mirror of
 help / color / mirror / Atom feed
* Do we actually need a “packages” field?
@ 2020-02-02 10:38 Ricardo Wurmus
  2020-02-02 12:06 ` zimoun
  0 siblings, 1 reply; 3+ messages in thread
From: Ricardo Wurmus @ 2020-02-02 10:38 UTC (permalink / raw)
  To: gwl-devel


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?


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-02-02 12:39 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-02 10:38 Do we actually need a “packages” field? Ricardo Wurmus
2020-02-02 12:06 ` zimoun
2020-02-02 12:39   ` Ricardo Wurmus

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