Hi all,
On +2019-11-06 18:07:09 +0100, Ludovic Courtès wrote:
> Hi Konrad,
>
> Konrad Hinsen <konrad.hin...@fastmail.net> 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
