what colour should the bikeshed have?

what colour should the bikeshed have?

[Ricardo Wurmus]

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

Re: what colour should the bikeshed have?

[zimoun]

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

Re: what colour should the bikeshed have?

[Ricardo Wurmus]

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

Re: what colour should the bikeshed have?

[Ricardo Wurmus]

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

Re: what colour should the bikeshed have?

[Ricardo Wurmus]

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