unofficial mirror of gwl-devel@gnu.org
 help / color / mirror / Atom feed
* what colour should the bikeshed have?
@ 2019-06-21 13:14 Ricardo Wurmus
  2019-06-24 10:23 ` zimoun
  2019-06-24 22:24 ` Ricardo Wurmus
  0 siblings, 2 replies; 5+ messages in thread
From: Ricardo Wurmus @ 2019-06-21 13:14 UTC (permalink / raw)
  To: gwl-devel

Hello there,

recently we changed some <process> field names (“package-inputs” and
“data-inputs”) and I thought that maybe we should talk about the
“procedure” field.

Currently, a process might look like this:

  process: greet
    packages "hello"
    procedure '(system "hello")

Or like this:

  process: sleep
    packages "coreutils"
    procedure # bash {
      echo "Sleeping..."
      sleep 10
    }

I think “procedure # bash {” is a bit long for a very common use case.
Since “# bash {…}” is special syntax implemented with a reader macro I’m
not sure if or how we can do better.

I think we might be able to do this:

  process: sleep
    packages "coreutils"
    # bash {
      echo "Sleeping..."
      sleep 10
    }

…if we somehow rewrote the reader macro to expand to the full field
definition, or if we changed the “process:” macro to expect a bare code
snippet at the end without the need for a field assignment, though this
would not be possible (or too ugly) in plain Scheme.

But even if we can’t do that, maybe we could just replace
the very long “procedure” with the much shorter “run”:

  process: sleep
    packages "coreutils"
    run # bash {
      echo "Sleeping..."
      sleep 10
    }

Obviously, this would work fine in plain Scheme.

What do you think?  Is it worth trying / doing?

--
Ricardo

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

* Re: what colour should the bikeshed have?
  2019-06-21 13:14 what colour should the bikeshed have? Ricardo Wurmus
@ 2019-06-24 10:23 ` zimoun
  2019-06-24 13:33   ` Ricardo Wurmus
  2019-06-25 15:32   ` Ricardo Wurmus
  2019-06-24 22:24 ` Ricardo Wurmus
  1 sibling, 2 replies; 5+ messages in thread
From: zimoun @ 2019-06-24 10:23 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: gwl-devel

Hi,

On Fri, 21 Jun 2019 at 15:14, Ricardo Wurmus <rekado@elephly.net> wrote:

> But even if we can’t do that, maybe we could just replace
> the very long “procedure” with the much shorter “run”:
>
>   process: sleep
>     packages "coreutils"
>     run # bash {
>       echo "Sleeping..."
>       sleep 10
>     }

[...]

> What do you think?  Is it worth trying / doing?

Nice !
Even, the keyword `run` seems  more talkative than `procedure`.


However, I am a bit lost. Does this process still work?

process: sleep
  packages "coreutils"
  run '(begin (display "Sleeping...\n")
                    (system* "sleep" "10"))

For consistency, why not?
  run # guile {
    blah
  }


And, is it better to declare explicitly "coreutils" as package input
when using bash?
Or implicitly? For example, if `run # python {}` is used then the
package input is implicitly python.
What do you think?


All the best,
simon

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

* Re: what colour should the bikeshed have?
  2019-06-24 10:23 ` zimoun
@ 2019-06-24 13:33   ` Ricardo Wurmus
  2019-06-25 15:32   ` Ricardo Wurmus
  1 sibling, 0 replies; 5+ messages in thread
From: Ricardo Wurmus @ 2019-06-24 13:33 UTC (permalink / raw)
  To: zimoun; +Cc: gwl-devel


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

> However, I am a bit lost. Does this process still work?
>
> process: sleep
>   packages "coreutils"
>   run '(begin (display "Sleeping...\n")
>                     (system* "sleep" "10"))

Yes.  The “procedure” field takes a plain S-expression, a G-expression,
or a code-snippet (which is what the “# ”-syntax produces).

> For consistency, why not?
>   run # guile {
>     blah
>   }

Because it’s unnecessary.  You can do this if you want a particular
variant of Guile, of course.

> And, is it better to declare explicitly "coreutils" as package input
> when using bash?
> Or implicitly? For example, if `run # python {}` is used then the
> package input is implicitly python.
> What do you think?

I want this to be implicit, but currently this is not yet possible.
Guix has no mechanism to collect inputs from G-expressions, so we can’t
automatically add the required inputs to the execution environment.
Ludo has a patch for remote evaluation, though, which adds features that
we can use for this purpose.

--
Ricardo

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

* Re: what colour should the bikeshed have?
  2019-06-21 13:14 what colour should the bikeshed have? Ricardo Wurmus
  2019-06-24 10:23 ` zimoun
@ 2019-06-24 22:24 ` Ricardo Wurmus
  1 sibling, 0 replies; 5+ messages in thread
From: Ricardo Wurmus @ 2019-06-24 22:24 UTC (permalink / raw)
  To: gwl-devel


Ricardo Wurmus <rekado@elephly.net> writes:

> I think “procedure # bash {” is a bit long for a very common use case.
> Since “# bash {…}” is special syntax implemented with a reader macro I’m
> not sure if or how we can do better.
>
> I think we might be able to do this:
>
>   process: sleep
>     packages "coreutils"
>     # bash {
>       echo "Sleeping..."
>       sleep 10
>     }

This works now since commit da8e0308587d62a06169dacdc41e86519a1ffa54.
Code snippets (either produced with the “#” syntax or without) are the
only thing that can make use of this special rule at the moment.  Plain
S-expressions need to use “procedure '(…)”, because I don’t really want
to match on “quote” and “quasiquote” at macro expansion time.

I didn’t implement special handling for G-expressions either, but that’s
possible in principle.

I’ll rename “procedure” to “run” next.

--
Ricardo

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

* Re: what colour should the bikeshed have?
  2019-06-24 10:23 ` zimoun
  2019-06-24 13:33   ` Ricardo Wurmus
@ 2019-06-25 15:32   ` Ricardo Wurmus
  1 sibling, 0 replies; 5+ messages in thread
From: Ricardo Wurmus @ 2019-06-25 15:32 UTC (permalink / raw)
  To: zimoun; +Cc: gwl-devel


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

> However, I am a bit lost. Does this process still work?
>
> process: sleep
>   packages "coreutils"
>   run '(begin (display "Sleeping...\n")
>                     (system* "sleep" "10"))

I should note that this will *not* work in a container because “sleep”
would not be found in the container environment.

> And, is it better to declare explicitly "coreutils" as package input
> when using bash?

“coreutils” only needs to be specified when they are used.  We need it
in the example because “sleep” is provided by “coreutils”.  That’s
unrelated to the use of Bash.

> Or implicitly? For example, if `run # python {}` is used then the
> package input is implicitly python.
> What do you think?

This is still on my list for when G-expressions are used (and it depends
on features that are waiting to arrive in Guix), but I just added
another convenience in commit 82ba9bad073d717c9e6fd9cf243cd6d94f674283.

If you don’t really care for bash and just want to use a shell you can
leave off the interpreter and default to /bin/sh.  This works now:

  process: greet
    packages "hello"
    # { hello }

--
Ricardo

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

end of thread, other threads:[~2019-06-25 15:32 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-21 13:14 what colour should the bikeshed have? Ricardo Wurmus
2019-06-24 10:23 ` zimoun
2019-06-24 13:33   ` Ricardo Wurmus
2019-06-25 15:32   ` Ricardo Wurmus
2019-06-24 22:24 ` 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