| Message ID | 20220314215015.24435-1-ludo@gnu.org |
|---|---|
| Headers | show |
| Series | Add 'guix manifest' to "translate" commands to manifests | expand |
Hi, Am Montag, dem 14.03.2022 um 22:50 +0100 schrieb Ludovic Courtès: > Hello Guix! > > Writing manifests can be intimidating: in part because it’s not > well documented, and in part because it’s always hard to start from > a blank page. > > We have ‘guix package --export-manifest’ to help with that, but I > realized that colleagues of mine often use ‘guix shell’ more than > ‘guix package’, and ‘--export-manifest’ is awkward to use: > > $ guix shell a b c d --transform=whatever=else > [env]$ guix package --export-manifest -p $GUIX_ENVIRONMENT > > I figured that instead of documenting this, we might as well provide > a command that does it in one go: > > guix manifest a b c d --transform=whatever=else > manifest.scm > > Voilà! > > Thoughts? The current implementation is missing the most important feature, which would be ‘guix manifest --profile $GUIX_PROFILE’ :) I think if we are to introduce a new command, we should make it handle existing use cases as well. If people then prefer ‘guix manifest’ over ‘guix package --export-manifest’, we can deprecate the old command in favor of the new one. Furthermore, one issue I have with both the existing and proposed approaches is that both mandate the specification style, whereas for operating system configs we typically prefer the variable style of referencing a package. Adding an option to choose between the two would be much appreciated from my side. Cheers
Hi Ludo, On Mon, 14 Mar 2022 at 22:53, Ludovic Courtès <ludo@gnu.org> wrote: > $ guix shell a b c d --transform=whatever=else > [env]$ guix package --export-manifest -p $GUIX_ENVIRONMENT > > I figured that instead of documenting this, we might as well provide > a command that does it in one go: > > guix manifest a b c d --transform=whatever=else > manifest.scm From my opinion, a complete subcommand for only one use case does not seem the right thing. Instead, IMHO, it would be better to have an extension for that. Because once we introduce a subcommand, it is hard to change (see 'guix environment') and since Guix provides this great extension mechanism, I think it is the path for this kind of niche use cases: start with an extension and depending on the "popularity" and interest then upstream. Well, if you think this feature is great to have in Guix proper, personally I would find more coherent: guix package --create-manifest a b c --transform=whatever=else > manifest.scm Cheers, simon
Hi zimoun, zimoun <zimon.toutoune@gmail.com> skribis: > On Mon, 14 Mar 2022 at 22:53, Ludovic Courtès <ludo@gnu.org> wrote: > >> $ guix shell a b c d --transform=whatever=else >> [env]$ guix package --export-manifest -p $GUIX_ENVIRONMENT >> >> I figured that instead of documenting this, we might as well provide >> a command that does it in one go: >> >> guix manifest a b c d --transform=whatever=else > manifest.scm > >>From my opinion, a complete subcommand for only one use case does not > seem the right thing. Instead, IMHO, it would be better to have an > extension for that. > > Because once we introduce a subcommand, it is hard to change (see > 'guix environment') and since Guix provides this great extension > mechanism, I think it is the path for this kind of niche use cases: > start with an extension and depending on the "popularity" and interest > then upstream. > > Well, if you think this feature is great to have in Guix proper, > personally I would find more coherent: > > guix package --create-manifest a b c --transform=whatever=else > > manifest.scm OTOH, sub-commands as just as cheap (and as expensive!) as command-line options. That is, one way or another, we’ll have to maintain the thing, whether it’s called ‘--create-manifest’ or ‘manifest’. To me, the argument in favor of the sub-command is that that it’s more discoverable, clearer, and easier to use. A user who has a ‘guix shell’ command line can replace ‘shell’ by ‘manifest’ and get their manifest. Thinking about it, another option would be to add an ‘--export-manifest’ option to ‘guix shell’ instead. Thoughts? Ludo’.
Hi, Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> skribis: > The current implementation is missing the most important feature, which > would be ‘guix manifest --profile $GUIX_PROFILE’ :) True, we could add ‘-p’ and make it equivalent to ‘guix package --export-manifest’. I think lack of ‘-p’ is not a showstopper though since ‘guix package --export-manifest’ remains available. [...] > Furthermore, one issue I have with both the existing and proposed > approaches is that both mandate the specification style, The reasons for the specification style are: 1. That it’s easier to implement reliably, since you just need to rely on package specs. 2. The resulting code is future-proof: if packages are moved from one module to another, or if their variables are renamed, it still works. 3. It’s a one-to-one mapping compared to the command line, which hopefully makes it clearer. However, ‘manifest->code’ existed before this patch series, so I think it’s beyond the scope of this review. Thanks, Ludo’.
Am Dienstag, dem 15.03.2022 um 10:27 +0100 schrieb Ludovic Courtès: > Hi, > > Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> skribis: > > > The current implementation is missing the most important feature, > > which would be ‘guix manifest --profile $GUIX_PROFILE’ :) > > True, we could add ‘-p’ and make it equivalent to ‘guix package > --export-manifest’. > > I think lack of ‘-p’ is not a showstopper though since ‘guix package > --export-manifest’ remains available. True, but implementing it as part of ‘guix manifest’ would open up a way to easily declare a manifest for “merged” profiles. These could be applied in integration testing, e.g. you could merge multiple profiles together and watch for intended and unintended side effects, for instance regarding search paths. > > Furthermore, one issue I have with both the existing and proposed > > approaches is that both mandate the specification style, > > The reasons for the specification style are: > > 1. That it’s easier to implement reliably, since you just need to > rely on package specs. > > 2. The resulting code is future-proof: if packages are moved from > one module to another, or if their variables are renamed, it > still works. > > 3. It’s a one-to-one mapping compared to the command line, which > hopefully makes it clearer. > > However, ‘manifest->code’ existed before this patch series, so I > think it’s beyond the scope of this review. It's true that it's out of scope, but I don't want this to be forgotten. I can see the rationale of specification style for user profiles, but for version-controlled package development manifests, there are different incentives in play. For example, you might want to make sure that a package uses gcc-toolchain from (gnu packages commencement) and not (google monorepo cc). Cheers
Hi, On Tue, 15 Mar 2022 at 10:23, Ludovic Courtès <ludo@gnu.org> wrote: > OTOH, sub-commands as just as cheap (and as expensive!) as command-line > options. That is, one way or another, we’ll have to maintain the thing, > whether it’s called ‘--create-manifest’ or ‘manifest’. I agree... > To me, the argument in favor of the sub-command is that that it’s more > discoverable, clearer, and easier to use. A user who has a ‘guix shell’ > command line can replace ‘shell’ by ‘manifest’ and get their manifest. ...but I am not convinced. :-) For instance, about discoverability, assuming "guix install / remove" would not be an alias of "guix package", then I would go va "guix help" then "guix install --help" then probably via "guix help" again, then "guix remove --help" etc. An extreme counter-example to your "clearer" point about subcommands is Git: I do not consider such many subcommands more discoverable because it gives the impression of a scattered mess. Subcommands provide a thematic hierarchy. For sure, it is a balance. :-) Because Guix is doing many many things, it is hard for people to understand, IMHO, therefore a sub-command hierarchy helps for catching the Guix features... I digress. :-) Well, my point is, for example, the logic of "guix system" then "guix system <action> <--options>" appears to me easier to grasp and discover. Idem with "guix import". I think "guix vm" or "guix image" would not ease the discoverability. What is unfortunate with "guix package" is that <action> and <--option> are both using dash-dash. Another story. :-) I am not convinced that promoting a niche use-case would be a good idea. For what my opinion is worth. Well, I trust your experience if you think it is better. > Thinking about it, another option would be to add an ‘--export-manifest’ > option to ‘guix shell’ instead. Thinking about it, it would be the most coherent from my point of view. And idem for --export-channels, no? Cheers, simon
Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> skribis: > Am Dienstag, dem 15.03.2022 um 10:27 +0100 schrieb Ludovic Courtès: >> Hi, >> >> Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> skribis: >> >> > The current implementation is missing the most important feature, >> > which would be ‘guix manifest --profile $GUIX_PROFILE’ :) >> >> True, we could add ‘-p’ and make it equivalent to ‘guix package >> --export-manifest’. >> >> I think lack of ‘-p’ is not a showstopper though since ‘guix package >> --export-manifest’ remains available. > True, but [...] What I meant is that I agree this is a useful addition, though one that could possibly come after. Thanks, Ludo’.
On Mon, Mar 14, 2022 at 5:53 PM Ludovic Courtès <ludo@gnu.org> wrote: > Next up: adding a “Writing Manifests” section. > Ludo', I would find this quite helpful. The current "basic setup with manifests" only documents the trivial case. It would be quite nice to document best practices for custom UTF-8 profiles, system-dependent inclusion (should we silently skip packages on unsupported systems?), and updating package versions, inputs, and/or toolchain. And for the latter, what are the limits of the manifest as compared with cloning, modifying, building, and executing with "./pre-inst-env guix ..." (which loses reproducibility)? Some background on that last thought: as Guix grows it becomes increasingly difficult to upgrade popular dependencies. I looked at upgrading 'fmt' and there was one dependent package that could not be upgraded, though not a package I needed. I'd like to be able to define an upgraded version of 'fmt' or 'boost' in my manifest and have it apply to the entire installation (profile or pack) rather than needing to modify specific packages with a with-input. Same for the toolchain, I think it would be nice to simply say "create this installation using gcc-toolchain" (the user default @11 rather than the system default @10) without needing any package transformations. And could one specify global build flags such as "-march=native"? Can one reach down into and modify commencement packages? Greg
Hi, zimoun <zimon.toutoune@gmail.com> skribis: > Well, my point is, for example, the logic of "guix system" then "guix > system <action> <--options>" appears to me easier to grasp and > discover. Idem with "guix import". I think "guix vm" or "guix image" > would not ease the discoverability. What is unfortunate with "guix > package" is that <action> and <--option> are both using dash-dash. > Another story. :-) I agree, ‘guix system’ and ‘guix import’ are pretty logical, consistent, and discoverable; ‘guix package’ less so… > I am not convinced that promoting a niche use-case would be a good > idea. For what my opinion is worth. Well, I trust your experience if > you think it is better. There have been proposals in the past to follow a similar three-level command scheme, such as ‘guix profile install’, etc. While this would be more “logical” in terms of categorization, it’s also less intuitive, requires more typing, and overall may well be less ergonomic than shorthands like ‘guix install’ or ‘guix edit’. For ‘guix install’, we were guided by the rule of least surprise. But it’s true that in the case of ‘guix manifest’, it’s less obvious because other package managers for instance don’t have such a command. >> Thinking about it, another option would be to add an ‘--export-manifest’ >> option to ‘guix shell’ instead. > > Thinking about it, it would be the most coherent from my point of > view. And idem for --export-channels, no? For ‘guix shell’ that would be strictly equivalent to ‘guix describe’. I’m not convinced having ‘--export-channels’ would bring anything. Thanks for your feedback! Ludo’.
Hi, Greg Hogan <code@greghogan.com> skribis: > I would find this quite helpful. The current "basic setup with manifests" > only documents the trivial case. It would be quite nice to document best > practices for custom UTF-8 profiles, system-dependent inclusion (should we > silently skip packages on unsupported systems?), and updating package > versions, inputs, and/or toolchain. OK. > And for the latter, what are the limits of the manifest as compared > with cloning, modifying, building, and executing with "./pre-inst-env > guix ..." (which loses reproducibility)? > > Some background on that last thought: as Guix grows it becomes > increasingly difficult to upgrade popular dependencies. I looked at > upgrading 'fmt' and there was one dependent package that could not be > upgraded, though not a package I needed. I'd like to be able to define an > upgraded version of 'fmt' or 'boost' in my manifest and have it apply to > the entire installation (profile or pack) rather than needing to modify > specific packages with a with-input. Same for the toolchain, I think it > would be nice to simply say "create this installation using gcc-toolchain" > (the user default @11 rather than the system default @10) without needing > any package transformations. And could one specify global build flags such > as "-march=native"? Can one reach down into and modify commencement > packages? This—switching compiler tool chains and tuning for a CPU—is available as package transformations: https://guix.gnu.org/manual/devel/en/html_node/Package-Transformation-Options.html You can take advantage of those in your manifest using ‘option->transformations’: https://guix.gnu.org/manual/devel/en/html_node/Defining-Package-Variants.html#index-options_002d_003etransformation The tentative ‘guix manifest’ and ‘guix package --export-manifest’ create that code snippet for you, as in this example: https://issues.guix.gnu.org/54393#2-lineno134 That’s the kind of thing I’d like to show in the “Writing Manifests” section. Tuning and switching tool chains will always happen through package transformations. In Guix, things have to be specified explicitly; there’s no way you can stealthily change the meaning of the dependency graph without changing it—unlike other tools in this area. But that’s a strength! Now, we have to make it so that such changes can be done conveniently, and package transformation options were introduced in this spirit. I hope that makes sense! Ludo’.