Re: Profiles/manifests-related command line interface enhancements

[Bengt Richter]

Hi all,

On +2019-11-06 18:07:09 +0100, Ludovic Courtès wrote:
> Hi Konrad,
> 
> Konrad Hinsen <address@hidden> skribis:
> 
> > Take the typical example from Docker tutorials: bundling a Web server
> > with some Web application and a database. It's easy to make a manifest
> > file for collecting the required packages. But it would make more sense
> > to me to have a module in a Guix channel that defines a parametrizable
> > super-package for the Web application that has no source code of its own
> > but various inputs and perhaps configuration files. Users can then
> > install several Web apps bundled in this fashion, sharing the Web
> > server. This kind of composition is not possible (currently) with
> > manifest files.
> 
> I agree this is an important use case.  It seems to me that the problem
> here is being able to aggregate more than just packages.
> 
> A manifest can contain any lowerable object, not just packages, but
> then, does it make much sense to use a manifest (and a profile) in this
> case?
> 
> The Web application example above seems to be somewhere between a mere
> <manifest> and an full-blown <operating-system>.  Perhaps we need an
> intermediate abstraction that bundles together a profile along with some
> lightweight services?
> 
> Or, to put it differently, how do we define “super-package”?
> 
> >> Profiles are managed by Guix, isn't it?
> >
> > Sure, but how exactly? Right now, a profile is a directory anywhere in
> > the file system that Guix knows about. Recent discussions have proposed
> > alternatives, such as keeping all of a user's profile in some directory
> > defined by convention and referring to them by name. What's the better
> > way to use as a default? I don't know, but I think we should discuss it
> > rather than adding new sub-commands with different behavior and thus
> > adding to the mess.
> 
> ‘guix package --list-profiles’ was added to improve this situation where
> there’s no enforced convention.
> 
> The question seems to be whether we should add more convention and less
> configuration.
> 
> I’m often reluctant to that, preferring self-contained commands where
> all the files involved appear on the command line.  However, I agree
> that it’s a tradeoff and there’s a balance to be found to make the CLI
> practical and convenient without making it obscure.  To that end, we
> should probably usefully move from “zero conventions” to “some
> conventions enforced” to improve over the current situation.
> 
> Examples of conventions discussed before:
> 
>   • Referring to profiles by name, meaning that users would no longer
>     explicitly manipulate symlinks that live anywhere on the file
>     system.
> 
>   • Having “guix environment” without arguments load an
>     ‘environment.scm’ file (or similar) from the current directory.
> 
> Are these things you have in mind?  Anything else?
> 
> We should boil that discussion down to a list of things to implement.
> :-)
> 
> Thanks!
> 
> Ludo’.
> 

1. guix explain EXAMPLE
as a quick way to get a definition of EXAMPLE from a guix glossary of terms and 
acronyms,
as well as references to example snippets etc. Also add easy ways to launch 
relevant links
to info or list archives or a wiki of troubleshooting experience, etc. in 
arbitrary URLs.

2. When implementing something, consider whether it could be useful as a 
separate script
that can be invoked from bash or on a region in emacs, vs being inaccessibly 
embedded,
and if useful, expose it in the current profile (or as directed).

As an example, putting snip-delimiters around some text could be done in elisp,
but it's more accessible and customizable as a script, e.g.,

--8<----(original did not do this)-----------cut 
here---------------start------------->8---
#!/usr/bin/env -S guile -e gxsnip -s
!#

(use-modules (ice-9 format))
(use-modules (ice-9 textual-ports))

(define (gxsnip args)
  (begin
    (let*((opt (cdr args))
          (tag (if (pair? opt)
                   (string-append "(" (string-join opt " ") ")")
                   "")))
      (format #t 
       "--8<----~a~a\n~a\n--8<----~a~a\n"
       tag
       "-----------cut here---------------start------------->8---"
       (get-string-all (current-input-port))
       tag
       "-----------cut here---------------end--------------->8---"
       ))))

--8<----(original did not do this)-----------cut 
here---------------end--------------->8---

Oops. still using /usr/bin/... there ;-)
And I see easy improvements, but my point is it would have been less shareable 
as an emacs-only macro.

Where guix is factorable into separately useful components, I think the same 
idea applies.
The unix way of small things :)
HTH
--
Regards,
Bengt Richter