Hi Konrad, On Tue, 5 Nov 2019 at 17:05, Konrad Hinsen <konrad.hin...@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
