Re: Profiles/manifests-related command line interface enhancements

[zimoun <zimon.toutoune@gmail.com>]

Hi Konrad,

On Tue, 5 Nov 2019 at 17:05, Konrad Hinsen <konrad.hinsen@fastmail.net> wrote:

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

To me, scenarii is how we combine the features.

Speaking about your example of "à la Docker" usage, except the
manifest composition, we could already write an usage scenario, I
guess.


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

From my opinion, it is not the problem of Guix. Guix should not force
a practise, as good it should be. The way the users share manifests is
the problem of users, not the Guix's one, IMHO.


> 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 do not understand very well what "guix deploy" is, but it is not
what it is doing?

(except the manifest composition that we agree both is missing; Pierre
mentioned us ;-))

From my opinion, Docker tutorials seems really easy because 1.
everything is centralized and 2. they cheat (it is hard to replay a
random tuto couple of months later; from my experience.)


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

A kind of plumbing manifest already exists. See <your-profile>/manifest.
But it is not compliant with the "--manifest" option.

Let consider the scenario:

  guix package --manifest manif.scm -p foo #1
  guix pull #2
  guix package -i pkg -p foo #3


Initially, I was thinking [1] that it should be nice to create again
the exact same profile than at the end of the step #3 using
foo/manifest. For example, sending to colleagues the file foo/manifest
and they just run:

  guix package --manifest foo-manifest.scm -p bar

So packages comes from 2 different commits: one from the Guix state at
step #1 or provided by manif.scm, another one from the Guix updated
state of step #2.

But reading thread elsewhere about manifest and so on, yours and
Pierre's arguments convinced me that it is the wrong way. Other said,
it will become a big mess with too much inferiors (because it does not
force the user to use the manifests).

Instead, after testing (or whatever) at the step #3, the user should
write the correct manifest corresponding to this step #3, say
other.scm. Then sending manif.scm and other.scm to colleagues and they
run:

   guix package -m manif.scm -m other.scm -p baz

And the profiles foo and baz contain the exact same binaries (hope so :-))


What is missing is an easy way to track the Guix commit state. If the
user runs the step #1 and the file manif.scm does not provide any
commit, then they needs to write down the Guix commit. And it is not
straightforward if they forgot and already run the step #2. However,
this information is currently tracked by Guix in the file
foo/manifest.


From what I understand, "guix time-machine" is the answer to this kind
of scenario. Right?


[1] https://lists.gnu.org/archive/html/guix-devel/2019-09/msg00228.html


> But then it would make sense for guix to manage manifest files in git
> repositories by default, to encourage good habits.

I agree. The same way than channel does.


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

I agree about "adding to the mess". :-)

Personally, I do not like the "directory defined by convention and
referring to them by name" approach. The "package manager" Conda does
that and after some years using it (before switching to Guix \o/),
this approach appears to be also a mess. I never remembered the name
of the profile so I was always doing "conda list -e" oups! wrong
command the other one "conda info -e" to list all the "environment"
names and then source the one I want.

I prefer the Guix way and I store the profile (symbolic link) in the
project directory. This way, I always remember the name, I can quickly
create another one with a cryptic name -- naming is hard :-) -- and
weeks later I remember that it is attached to this project.

I understand the use-case described in the Pierre's blog post but this
use-case is mainly not mine and I am happy with the "scattered"
approach. :-)


About the subcommand mess, what should help IMHO should be to be able
to easily create "alias" and/or new subcommands distributed with
channels. I did not know before reading this bug report [2].


[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37399



All the best,
simon