Re: Profiles/manifests-related command line interface enhancements

[Konrad Hinsen]

Hi Simon,

> I am not sure to see which feature is missing.

My main point is that the future evolution of functionality (and user
interfaces) in this space should take into account usage scenarii,
rather than adding features in an ad-hoc fashion.

I can of course share a manifest file by putting it in a public
repository. But that isn't necessarily the best way.

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.

> From my point of view, ephemeral (environment) vs persistent (profile)
> depends on use-case but at the end the only concern is: how to
> populate them? And the only answer should be: declarative (manifest);
> the ad-hoc (package -i) should not be the usual way but only a
> quick&dirt test.

I agree. So maybe each profile should have an associated manifest file,
with "guix install" merely adding to it and the updating the profile.
But then it would make sense for guix to manage manifest files in git
repositories by default, to encourage good habits.

>> This third dimension also
>> raises the question of where the information (profiles, manifests, ...)
>> are stored and managed (version control?),
>
> 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.

> Manifests are managed by the user. And they does what they wants. ;-)

True again, but again, is that the best way to do it?

Cheers,
  Konrad.