Re: Profiles/manifests-related command line interface enhancements

[Konrad Hinsen]

Hi Ludo,

> I’d like to think that writing Guile declarations for the OS config,
> manifest, etc. is not just for “power users”.  After all people, or
> rather “computer-savvy” people in a broad sense, write JSON, YAML,
> custom config files etc. routinely, and I don’t think the typical config
> we propose is any “harder”.  You may say I’m a dreamer, but I’m not the
> only one. 𝅗𝅥𝅘𝅥  ;-)

The problem with powerful formal languages (read: Turing-complete) is
not writing, but (1) debugging and (2) reading.

1. Writing a manifest file in Guile is no harder than writing a list
   in YAML or whatever. But leave out the closing quote behind a
   package name, and you will get an error message that will make
   no sense to someone unfamiliar with the *complete* Scheme syntax.
   For a small and simple file, you can usually spot the problem by
   inspection (i.e. without the error message), but for more complex
   files, it makes sense to use a more constrained language in order
   to provide better error reporting.

   BTW, the Racket team makes that point to argue for their rather
   complex macro system. It takes much longer to master than traditional
   Lisp or Scheme macros, but it supports writing macros with error
   reporting that makes sense to someone who didn't read the macro code.

2. Power users will always write code in powerful languages that exceed
   what less advanced users can deal with. And since power users are not
   necessarily benevolent, this creates a trust issue for the less
   advanced ones.

For a long version of these arguments, see
   https://hal.archives-ouvertes.fr/hal-01966145/document

> I think we need to focus on specific scenarios though.

Definitely!

> IOW, users of a channel have to trust it to not be malicious,
> regardless of the fact that its Guile code runs unrestricted.

Yes. That's perhaps something that the manual should point out
explicitly. Also, a more specific user interface ("guix channel add
URL") could show a warning.

> For manifests shared over the net, the situation may be different: a
> manifest could refer to packages in the channels you trust, and thus
> there’s value in not having to trust the manifest code itself.

Exactly, and that's the idea that got me into this thread.

> It’s still a bit too abstract, but for the purposes of sharing and
> publishing “super packages” as you wrote, we could define a
> purely-declarative format (could be JSON, could be Guile code that can
> run under (ice-9 sandbox) or with ‘eval/container’) that people could
> use instead unrestricted as is currently the case.

Yes, that's one way to go. BTW, I didn't know about eval/container,
I'll have to look at it!

Cheers,
  Konrad.