Re: Profiles/manifests-related command line interface enhancements

["Ludovic Courtès" <ludo@gnu.org>]

Hi Konrad,

Konrad Hinsen <konrad.hinsen@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’.