[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Profiles/manifests-related command line interface enhancements

From: Bengt Richter
Subject: Re: Profiles/manifests-related command line interface enhancements
Date: Wed, 6 Nov 2019 14:21:35 -0800
User-agent: Mutt/1.12.1 (2019-06-15)

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 
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 
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 
#!/usr/bin/env -S guile -e gxsnip -s

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

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

--8<----(original did not do this)-----------cut 

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 :)
Bengt Richter

reply via email to

[Prev in Thread] Current Thread [Next in Thread]