Hey! Konrad Hinsen <konrad.hin...@fastmail.net> skribis:
> Pierre Neidhardt <m...@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’.
