unofficial mirror of gwl-devel@gnu.org
 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

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

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

* Re: Do we actually need a “packages” field?
  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
  0 siblings, 1 reply; 3+ messages in thread
From: zimoun @ 2020-02-02 12:06 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

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

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

* Re: Do we actually need a “packages” field?
  2020-02-02 12:06 ` zimoun
@ 2020-02-02 12:39   ` Ricardo Wurmus
  0 siblings, 0 replies; 3+ messages in thread
From: Ricardo Wurmus @ 2020-02-02 12:39 UTC (permalink / raw)
  To: zimoun; +Cc: gwl-devel


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

^ 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 gwl-devel@gnu.org

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://yhetil.org/gwl/0 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/ https://yhetil.org/gwl \
		gwl-devel@gnu.org
	public-inbox-index gwl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://news.yhetil.org/yhetil.gnu.guix.gwl


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git