guix-devel
[Top][All Lists]
Advanced

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

Re: Profiles/manifests-related command line interface enhancements


From: Konrad Hinsen
Subject: Re: Profiles/manifests-related command line interface enhancements
Date: Thu, 07 Nov 2019 14:52:19 +0100

Hi Ludo,

> 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.

Yes, it's a bit more than that. We'd probably have to look at a couple
of use cases to see what the most general content would be.

> 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”?

That's the question. I don't pretend to have an answer, I just wanted to
raise the question.

There are use cases, such as Web servers, that move towards the service
or even system abstraction. Other use cases would be just packages
plus configuration, with no automatic execution implied.

> ‘guix package --list-profiles’ was added to improve this situation where
> there’s no enforced convention.

Unfortunately it makes no distinction between package profiles
and channel profiles, so it's hard to use in scripts.

> The question seems to be whether we should add more convention and less
> configuration.

Or have all configuration in a single file per user, with convenient
defaults encoding a set of conventions. Trying to please everyone :-)

Right now the only conventions I can think of are the two default
profile names (~/.guix-profile for packages and ~/.config/guix/current
for channels). And I wonder BTW if the latter is not an abuse of
~/.config, given that it contains a ton of software rather than just
small configuration files, but that's a different question.

> We should boil that discussion down to a list of things to implement.
> :-)

Definitely. But I'd like to start by compiling a list of use cases,
to see how well they are served by what we have and then how they
could be served better.

Cheers,
  Konrad.



reply via email to

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