Re: Profiles/manifests-related command line interface enhancements

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

Hey!

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

> Pierre Neidhardt <mail@ambrevar.xyz> writes:
>
>> I'm actually surprised you find it surprising! :)
>> I can think of Simon, maybe Konrad(?) and myself who mentioned it
>> before.
>
> Yes, me too. I could add to Pierre's list of use cases, but I prefer to
> shift the discussion to a higher level.

Just to be clear: I think supporting multiple ‘--manifest’ flags in all
the commands would be welcome.  It’s probably a rather simple change,
and if it’s useful, go for it!

> What we have been discussing here recently is the organization of
> software one level above packages. The vague idea is "groups of packages
> that go together". Outside of the Guix universe, this is the realm of
> (Docker) containers. A quick look at what happens in that universe
> shows that composing such groups of packages corresponds to a frequent
> need (see docker compose, Kubernetes, ...).

Yes, I see.

> In Guix we have ephemeral (environment) vs. persistent (profile), ad-hoc
> (package -i, environment from package lists, ...) and declarative
> (manifests). It's a bit of a mess. Hacks such as "environment -r" show
> that we ought to think about a better overall design. In addition to the
> two dimensions I mentioned, this should include shareable/re-usable
> vs. personal. People publish and share Docker images, so why wouldn't
> they publish and share Guix super-packages? This third dimension also
> raises the question of where the information (profiles, manifests, ...)
> are stored and managed (version control?), and how they are referred to
> (name, filename, ...). And of course how they are composed - in Guile,
> at the shell level, or yet something else?

I think having ephemeral + persistent and declarative + imperative is
cool—I’d call that “flexible” rather than “messy”.  :-)

It’s great to have “guix install” as an entry point; I’m sure it allows
us to reach out to more people, and that matters too.  (I actually use
it, BTW, so it’s not an expert vs. newbie thing!)

I agree that sharing and publishing is important, and I think manifests
support that.  I think we need to support “unions” of manifests, and
that means (as always) supporting it at the API level and at the
command-line level (allowing for multiple ‘--manifest’ flags).

What we’re now saying is “look, you can write a manifest, and then you
can have it under version-control and publish it and it’s all up to you
how you do that”; but you seem to suggest that we should offer a
higher-level, more integrated solution, is that correct?

Like, we would enforce certain conventions by default, perhaps have
direct Git integration so that one can refer to a “manifest” just like
they refer to a channel, things like that.  Do I get it right?

I haven’t thought much about this but that sounds like an exciting
direction!

Thanks,
Ludo’.