| Message ID | 20210116182957.31075-1-ludo@gnu.org |
|---|---|
| Headers | show |
Hi there! Ludovic Courtès <ludo@gnu.org> skribis: > Here’s a simple but oft-requested feature (I remember discussing > with Pierre and Simon a year ago at the Guix Days about ways to > implement it—time flies!): these patches provide ‘guix package > --export-manifest’ and ‘--export-channels’. These options spit > a manifest and a channel spec, respectively, with the goal of > helping users who wish to migrate to the declarative model. I’m rather happy with this patch set but since this is something we’ve discussed several times in the past, I think it’d be great if those interested could chime in and comment: https://issues.guix.gnu.org/45919 I’ll leave a few more days and then… push! TIA, Ludo’.
Hi Ludo, On Wed, 27 Jan 2021 at 14:14, Ludovic Courtès <ludo@gnu.org> wrote: > Ludovic Courtès <ludo@gnu.org> skribis: > >> Here’s a simple but oft-requested feature (I remember discussing >> with Pierre and Simon a year ago at the Guix Days about ways to >> implement it—time flies!): these patches provide ‘guix package >> --export-manifest’ and ‘--export-channels’. These options spit >> a manifest and a channel spec, respectively, with the goal of >> helping users who wish to migrate to the declarative model. > > I’m rather happy with this patch set but since this is something we’ve > discussed several times in the past, I think it’d be great if those > interested could chime in and comment: > > https://issues.guix.gnu.org/45919 > > I’ll leave a few more days and then… push! You are looking at me? :-) Well, the feature is nice! At first, I thought that it could be a bit smarter than using only one commit. But as you said, the aim is for transitioning. Maybe a future improvement should to list somewhere in the comments which commit provides which set of packages. It could help… or not. :-) Using Docker, it works. Let describe how in case people are interested. On machine A, I have: --8<---------------cut here---------------start------------->8--- $ guix describe -f channels (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "cb68ae668af2ade4b0777d82f227e5462768e9e5") (introduction (make-channel-introduction "9edb3f66fd807b096b48283debdcddccfea34bad" (openpgp-fingerprint "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA"))))) $ cat ~/.config/guix/manifests/python.scm (specifications->manifest (append '("python" ) (map (lambda (pkg) (string-append "python-" pkg)) '("ipython" "numpy" "matplotlib" "scipy" "biopython" )))) --8<---------------cut here---------------end--------------->8--- And I generate a Docker pack with: --8<---------------cut here---------------start------------->8--- $ guix pack -f docker --save-provenance -m ~/.config/guix/manifests/python.scm /gnu/store/wxymmnxdvdvf08ifsfy39xjaxilhrigk-docker-pack.tar.gz --8<---------------cut here---------------end--------------->8--- Then on machine B, after fetching this tarball, I run: --8<---------------cut here---------------start------------->8--- $ docker load < /tmp/img/wxymmnxdvdvf08ifsfy39xjaxilhrigk-docker-pack.tar.gz $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE python-python-ipython-python-numpy latest 49ddfedf1e27 51 years ago 1.45GB --8<---------------cut here---------------end--------------->8--- And it works as expected: --8<---------------cut here---------------start------------->8--- $ docker run -ti python-python-ipython-python-numpy:latest python3 Python 3.8.2 (default, Jan 1 1970, 00:00:01) [GCC 7.5.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! >>> import numpy as np >>> A = np.array([[1,0,1],[0,1,0],[0,0,1]]) >>> _, s, _ = np.linalg.svd(A); s; abs(s[0] - 1./s[2]) array([1.61803399, 1. , 0.61803399]) 0.0 >>> --8<---------------cut here---------------end--------------->8--- Neat! So far, so good. Well, let extract the ’manifest’ from this Docker blob. --8<---------------cut here---------------start------------->8--- $ docker export -o /tmp/img/re-pack.tar $(docker ps -a --format "{{.ID}}" | head -n1) $ tar -xf /tmp/img/re-pack.tar $(tar -tf /tmp/img/re-pack.tar | grep 'profile/manifest') $ cat gnu/store/7frdchgf5sqw8b83azsml3lw0h52gfbk-profile/manifest | grep -E "(\(\"python|cb68ae)" | head -n5 (("python" "cb68ae668af2ade4b0777d82f227e5462768e9e5") ("python-ipython" (("python-backcall" ("python-pyzmq" --8<---------------cut here---------------end--------------->8--- Now, a trick to get the channels and specifications: --8<---------------cut here---------------start------------->8--- $ ./pre-inst-env guix package -p /tmp/img/gnu/store/7frdchgf5sqw8b83azsml3lw0h52gfbk-profile --export-channels ;; This channel file can be passed to 'guix pull -C' or to ;; 'guix time-machine -C' to obtain the Guix revision that was ;; used to populate this profile. (list (channel (name 'guix) (url "https://git.savannah.gnu.org/git/guix.git") (commit "cb68ae668af2ade4b0777d82f227e5462768e9e5") (introduction (make-channel-introduction "9edb3f66fd807b096b48283debdcddccfea34bad" (openpgp-fingerprint "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA")))) ) $ ./pre-inst-env guix package -p /tmp/img/gnu/store/7frdchgf5sqw8b83azsml3lw0h52gfbk-profile --export-manifest $ ./pre-inst-env guix package -p /tmp/img/gnu/store/7frdchgf5sqw8b83azsml3lw0h52gfbk-profile --export-manifest ;; This "manifest" file can be passed to 'guix package -m' to reproduce ;; the content of your profile. This is "symbolic": it only specifies ;; package names. To reproduce the exact same profile, you also need to ;; capture the channels being used, as returned by "guix describe". ;; See the "Replicating Guix" section in the manual. (specifications->manifest (list "python" "python-ipython" "python-numpy" "python-matplotlib" "python-scipy" "python-biopython")) --8<---------------cut here---------------end--------------->8--- Awesome! The unexpected is this channels and manifests files do not reproduce the same Docker pack tarball: --8<---------------cut here---------------start------------->8--- $ guix describe Generation 99 Jan 05 2021 16:56:39 (current) guix-past 829923f repository URL: https://gitlab.inria.fr/guix-hpc/guix-past branch: master commit: 829923f01f894f1e687735627025ada26230832f guix-bimsb a8b539d repository URL: https://github.com/BIMSBbioinfo/guix-bimsb branch: master commit: a8b539d61a359060c35f3cb34c7edd1d9d14241d bimsb-nonfree 4084e63 repository URL: https://github.com/BIMSBbioinfo/guix-bimsb-nonfree.git branch: master commit: 4084e63c9c0d662780870aded9f5a6ca1b063780 guix-science cf87b05 repository URL: https://github.com/guix-science/guix-science.git branch: master commit: cf87b0501c4a38b96edf41025a27bf1cb91f521a guix 957f0c4 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 957f0c40327ce00f53db22737e3775ce616ac258 $ guix time-machine -C /tmp/img/channels.scm -- pack -f docker --save-provenance -m /tmp/img/manifest.scm Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... /gnu/store/xzk604g8gysv4azn7sf9nylr6iah97gl-docker-pack.tar.gz --8<---------------cut here---------------end--------------->8--- To compare with /gnu/store/wxymmnxdvdvf08ifsfy39xjaxilhrigk-docker-pack.tar.gz. On a third machine, I get: /gnu/store/wxymmnxdvdvf08ifsfy39xjaxilhrigk-docker-pack.tar.gz Well, that’s another story and I have not inspected yet the derivations and what could be wrong on the machine B. Cheers, simon
Hi Ludo! Ludovic Courtès <ludo@gnu.org> writes: > Ludovic Courtès <ludo@gnu.org> skribis: > >> Here’s a simple but oft-requested feature (I remember discussing >> with Pierre and Simon a year ago at the Guix Days about ways to >> implement it—time flies!): these patches provide ‘guix package >> --export-manifest’ and ‘--export-channels’. These options spit >> a manifest and a channel spec, respectively, with the goal of >> helping users who wish to migrate to the declarative model. > > I’m rather happy with this patch set but since this is something we’ve > discussed several times in the past, I think it’d be great if those > interested could chime in and comment: > > https://issues.guix.gnu.org/45919 > > I’ll leave a few more days and then… push! Thanks a lot for working on this, I'll try to give it a shot tomorrow! :)
Hi zimoun, Thank you for your tutorial-style and resource-reference-footnoted posts! I don't know about others, but I save many on my hard disk as reference examples. I hope this provides positive feedback for your efforts. Thank you. On +2021-01-27 22:02:53 +0100, zimoun wrote: > Hi Ludo, > > On Wed, 27 Jan 2021 at 14:14, Ludovic Courtès <ludo@gnu.org> wrote: > > Ludovic Courtès <ludo@gnu.org> skribis: > > > >> Here’s a simple but oft-requested feature (I remember discussing > >> with Pierre and Simon a year ago at the Guix Days about ways to > >> implement it—time flies!): these patches provide ‘guix package > >> --export-manifest’ and ‘--export-channels’. These options spit > >> a manifest and a channel spec, respectively, with the goal of > >> helping users who wish to migrate to the declarative model. > > > > I’m rather happy with this patch set but since this is something we’ve > > discussed several times in the past, I think it’d be great if those > > interested could chime in and comment: > > > > https://issues.guix.gnu.org/45919 > > > > I’ll leave a few more days and then… push! > > You are looking at me? :-) > > Well, the feature is nice! At first, I thought that it could be a bit > smarter than using only one commit. But as you said, the aim is for > transitioning. Maybe a future improvement should to list somewhere in > the comments which commit provides which set of packages. It could > help… or not. :-) > > Using Docker, it works. Let describe how in case people are interested. > > > On machine A, I have: > > --8<---------------cut here---------------start------------->8--- > $ guix describe -f channels > (list (channel > (name 'guix) > (url "https://git.savannah.gnu.org/git/guix.git") > (commit > "cb68ae668af2ade4b0777d82f227e5462768e9e5") > (introduction > (make-channel-introduction > "9edb3f66fd807b096b48283debdcddccfea34bad" > (openpgp-fingerprint > "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA"))))) > > $ cat ~/.config/guix/manifests/python.scm > (specifications->manifest > (append > '("python" > ) > (map > (lambda (pkg) > (string-append "python-" pkg)) > '("ipython" > "numpy" > "matplotlib" > "scipy" > "biopython" > )))) > --8<---------------cut here---------------end--------------->8--- > > And I generate a Docker pack with: > > --8<---------------cut here---------------start------------->8--- > $ guix pack -f docker --save-provenance -m ~/.config/guix/manifests/python.scm > /gnu/store/wxymmnxdvdvf08ifsfy39xjaxilhrigk-docker-pack.tar.gz > --8<---------------cut here---------------end--------------->8--- > > > Then on machine B, after fetching this tarball, I run: > > --8<---------------cut here---------------start------------->8--- > $ docker load < /tmp/img/wxymmnxdvdvf08ifsfy39xjaxilhrigk-docker-pack.tar.gz > $ docker images > REPOSITORY TAG IMAGE ID CREATED SIZE > python-python-ipython-python-numpy latest 49ddfedf1e27 51 years ago 1.45GB > --8<---------------cut here---------------end--------------->8--- > > And it works as expected: > > --8<---------------cut here---------------start------------->8--- > $ docker run -ti python-python-ipython-python-numpy:latest python3 > Python 3.8.2 (default, Jan 1 1970, 00:00:01) > [GCC 7.5.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> import this > The Zen of Python, by Tim Peters > > Beautiful is better than ugly. > Explicit is better than implicit. > Simple is better than complex. > Complex is better than complicated. > Flat is better than nested. > Sparse is better than dense. > Readability counts. > Special cases aren't special enough to break the rules. > Although practicality beats purity. > Errors should never pass silently. > Unless explicitly silenced. > In the face of ambiguity, refuse the temptation to guess. > There should be one-- and preferably only one --obvious way to do it. > Although that way may not be obvious at first unless you're Dutch. > Now is better than never. > Although never is often better than *right* now. > If the implementation is hard to explain, it's a bad idea. > If the implementation is easy to explain, it may be a good idea. > Namespaces are one honking great idea -- let's do more of those! > >>> import numpy as np > >>> A = np.array([[1,0,1],[0,1,0],[0,0,1]]) > >>> _, s, _ = np.linalg.svd(A); s; abs(s[0] - 1./s[2]) > array([1.61803399, 1. , 0.61803399]) > 0.0 > >>> > --8<---------------cut here---------------end--------------->8--- > > Neat! > > So far, so good. Well, let extract the ’manifest’ from this Docker > blob. > > --8<---------------cut here---------------start------------->8--- > $ docker export -o /tmp/img/re-pack.tar $(docker ps -a --format "{{.ID}}" | head -n1) > $ tar -xf /tmp/img/re-pack.tar $(tar -tf /tmp/img/re-pack.tar | grep 'profile/manifest') > $ cat gnu/store/7frdchgf5sqw8b83azsml3lw0h52gfbk-profile/manifest | grep -E "(\(\"python|cb68ae)" | head -n5 > (("python" > "cb68ae668af2ade4b0777d82f227e5462768e9e5") > ("python-ipython" > (("python-backcall" > ("python-pyzmq" > --8<---------------cut here---------------end--------------->8--- > > Now, a trick to get the channels and specifications: > > --8<---------------cut here---------------start------------->8--- > $ ./pre-inst-env guix package -p /tmp/img/gnu/store/7frdchgf5sqw8b83azsml3lw0h52gfbk-profile --export-channels > ;; This channel file can be passed to 'guix pull -C' or to > ;; 'guix time-machine -C' to obtain the Guix revision that was > ;; used to populate this profile. > > (list > (channel > (name 'guix) > (url "https://git.savannah.gnu.org/git/guix.git") > (commit > "cb68ae668af2ade4b0777d82f227e5462768e9e5") > (introduction > (make-channel-introduction > "9edb3f66fd807b096b48283debdcddccfea34bad" > (openpgp-fingerprint > "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA")))) > ) > > $ ./pre-inst-env guix package -p /tmp/img/gnu/store/7frdchgf5sqw8b83azsml3lw0h52gfbk-profile --export-manifest > $ ./pre-inst-env guix package -p /tmp/img/gnu/store/7frdchgf5sqw8b83azsml3lw0h52gfbk-profile --export-manifest > ;; This "manifest" file can be passed to 'guix package -m' to reproduce > ;; the content of your profile. This is "symbolic": it only specifies > ;; package names. To reproduce the exact same profile, you also need to > ;; capture the channels being used, as returned by "guix describe". > ;; See the "Replicating Guix" section in the manual. > > (specifications->manifest > (list "python" > "python-ipython" > "python-numpy" > "python-matplotlib" > "python-scipy" > "python-biopython")) > --8<---------------cut here---------------end--------------->8--- > > Awesome! > > > The unexpected is this channels and manifests files do not reproduce the > same Docker pack tarball: > > --8<---------------cut here---------------start------------->8--- > $ guix describe > Generation 99 Jan 05 2021 16:56:39 (current) > guix-past 829923f > repository URL: https://gitlab.inria.fr/guix-hpc/guix-past > branch: master > commit: 829923f01f894f1e687735627025ada26230832f > guix-bimsb a8b539d > repository URL: https://github.com/BIMSBbioinfo/guix-bimsb > branch: master > commit: a8b539d61a359060c35f3cb34c7edd1d9d14241d > bimsb-nonfree 4084e63 > repository URL: https://github.com/BIMSBbioinfo/guix-bimsb-nonfree.git > branch: master > commit: 4084e63c9c0d662780870aded9f5a6ca1b063780 > guix-science cf87b05 > repository URL: https://github.com/guix-science/guix-science.git > branch: master > commit: cf87b0501c4a38b96edf41025a27bf1cb91f521a > guix 957f0c4 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: 957f0c40327ce00f53db22737e3775ce616ac258 > > $ guix time-machine -C /tmp/img/channels.scm -- pack -f docker --save-provenance -m /tmp/img/manifest.scm > Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... > /gnu/store/xzk604g8gysv4azn7sf9nylr6iah97gl-docker-pack.tar.gz > --8<---------------cut here---------------end--------------->8--- > > To compare with > /gnu/store/wxymmnxdvdvf08ifsfy39xjaxilhrigk-docker-pack.tar.gz. > > On a third machine, I get: > /gnu/store/wxymmnxdvdvf08ifsfy39xjaxilhrigk-docker-pack.tar.gz > > Well, that’s another story and I have not inspected yet the > derivations and what could be wrong on the machine B. > > > Cheers, > simon > KUTGW ;-)
zimoun <zimon.toutoune@gmail.com> writes: >> I just had a cursory look, and my main concern is that maybe exposing >> commands is one more thing to learn for the user, and one more step to >> run to get a simple file. >> >> Instead, what about doing what system profiles already do with >> >> /run/current-system/channels.scm >> /run/current-system/configuration.scm >> >> and store the result of the proposed commands directly in >> $PROFILE/channels.scm and $PROFILE/manifest-spec.scm, on each profile >> upgrade? > > If I understand correctly, Pierre, you are proposing 2 things: 1) only > one command and 2) export by default in $PROFILE. Right? > > Yeah, sounds a good idea to me. Even if #2 seems a bit of re-work for > the patch set. :-) Sorry, misunderstanding :) I'm proposing: 1) Zero command :p 2) On every profile modification (install, upgrade, removal), store the channel description and the manifest specification (as produced by this patch commands) to $GUIX_PROFILE/channels.scm and $GUIX_PROFILE/manifest-spec.scm, respectively. ($GUIX_PROFILE being the target profile, of course.) Does that make more sense?
Hi, On Fri, 29 Jan 2021 at 22:51, Pierre Neidhardt <mail@ambrevar.xyz> wrote: > Sorry, misunderstanding :) Have a drink together is missing because these times we have communication issues. :-) > I'm proposing: > > 1) Zero command :p > > 2) On every profile modification (install, upgrade, removal), store the > channel description and the manifest specification (as produced by this > patch commands) to $GUIX_PROFILE/channels.scm and > $GUIX_PROFILE/manifest-spec.scm, respectively. > > ($GUIX_PROFILE being the target profile, of course.) > > Does that make more sense? Yes, but it needs a lot of re-work and change, IMHO. And we ends with 3 files: $GUIX_PROFILE/manifest capturing the states of $GUIX_PROFILE and the 2 others deducing an approximation of these states. Well, IMHO, automatically produce this approximation at each «action» on the profile adds complexity and I am not convinced it is worth. Cheers, simon
Hi, zimoun <zimon.toutoune@gmail.com> skribis: > Yes, but it needs a lot of re-work and change, IMHO. And we ends with 3 > files: $GUIX_PROFILE/manifest capturing the states of $GUIX_PROFILE and > the 2 others deducing an approximation of these states. Well, IMHO, > automatically produce this approximation at each «action» on the profile > adds complexity and I am not convinced it is worth. Yeah. Actually, part of the code would be shared anyway, so we could always go with ‘--export-manifest’ first and think about adding the extra files later. (Though I’m still unsure about these extra files, TBH.) Ludo’.
Hi! Ludovic Courtès <ludo@gnu.org> writes: > Here are practical issues that come to mind: > > • It would only work for newer profiles, created after the feature has > been implemented (maybe that’s okay). Indeed, I think it's OK! :) > • The generated files might use APIs that, in the meantime, got > deprecated or changed somehow. This is in contrast with > ‘--export-profile’, which interprets ‘manifest’ (a versioned file > format) and produces code that can use the API du jour. /run/current-system/configuration.scm suffers from the same problem. But with the manifest we could do better, we could include a version number one way or another. Besides, since it comes together with channels.scm, we know which Guix was used, so we always have access to the Guix with the right API to install the manifest. All in all, I think this is not a problem. > • One would still have to learn about these two files, and pick the > right “manifest” file. I think it would be easier than a command. See below. > • For users of ‘-m my-manifest.scm’, we would need to store > ‘my-manifest.scm’ as is instead of generating an approximation > thereof. Which seems easy to do, isn't it? Another use-case which I find useful and comes close to this feature is that of channel/manifest versioning, in the sense of keeping these files under version control for instance in a Git repository. This can be useful to keep the history of everything, even deleted generations, or even in case of hardware failure. To that end, it'd be nice if we could export these files automatically to a designated location. Example: I update ~/my-profile and it automatically produces / overwrite ~/repos/guix-profile-metadata.git/my-profile/channels.scm and ~/repos/guix-profile-metadata.git/my-profile/manifest.scm. This way I can commit these 2 files in my guix-profile-metadata.git repository. Food for thoughts :)
Hi, Pierre Neidhardt <mail@ambrevar.xyz> skribis: > Ludovic Courtès <ludo@gnu.org> writes: [...] >> • The generated files might use APIs that, in the meantime, got >> deprecated or changed somehow. This is in contrast with >> ‘--export-profile’, which interprets ‘manifest’ (a versioned file >> format) and produces code that can use the API du jour. > > /run/current-system/configuration.scm suffers from the same problem. Not really because it’s precisely the file that you gave to build the system. So you know you can run: cd /run/current-system guix time-machine -C channels.scm -- system reconfigure configuration.scm and it’ll work (modulo the documented caveats). > But with the manifest we could do better, we could include a version > number one way or another. > Besides, since it comes together with channels.scm, we know which Guix > was used, so we always have access to the Guix with the right API to > install the manifest. Right. >> • One would still have to learn about these two files, and pick the >> right “manifest” file. > > I think it would be easier than a command. See below. > >> • For users of ‘-m my-manifest.scm’, we would need to store >> ‘my-manifest.scm’ as is instead of generating an approximation >> thereof. > > Which seems easy to do, isn't it? I take it that you’re volunteering? :-) Nothing’s difficult, but in this case we’d need to pass the original manifest down to ‘profile-generation’. Requires some redesign. > Another use-case which I find useful and comes close to this feature is > that of channel/manifest versioning, in the sense of keeping these files > under version control for instance in a Git repository. This can be > useful to keep the history of everything, even deleted generations, or > even in case of hardware failure. > > To that end, it'd be nice if we could export these files automatically > to a designated location. > > Example: I update ~/my-profile and it automatically produces / overwrite > ~/repos/guix-profile-metadata.git/my-profile/channels.scm and > ~/repos/guix-profile-metadata.git/my-profile/manifest.scm. > > This way I can commit these 2 files in my guix-profile-metadata.git > repository. I guess you could do that either with ‘cp ~/.guix-profile/{channels,manifest.scm …’ or with ‘guix package --export-manifest … > …’. But again, that’s not really the goal here. The goal is to help users willing to migrate from the “imperative” mode to the declarative mode. Once you’re using a manifest, probably you’ll want to put that under version control, but that’s already the case. Thanks, Ludo’.
Hi, Ryan Prior <ryanprior@hey.com> skribis: > I don't think there's much drawback to having both the auto-generated > files and a command that generates them. That seems more discoverable - > you might happen across the files when you poke into a profile, or you > might notice the command while reading the docs or the help output. Note that the ‘manifest’ file starts with a comment. This patch set updates this comment so it mentions ‘--export-channels’. > Glad to see this capability land any which way, this is something that > comes up often! Heh, good. :-) > While we're considering putting a manifest in the profile, is this a > good time to also bring up the idea of renaming the "manifest" file? It > confuses more people all the time. I'd be inclined to rename it > "profile-metadata" or "lockfile". It’s the kind of thing that can’t really be changed, or at least not without a looong transition period, because older ‘guix package’ commands wouldn’t recognize profiles that lack a ‘manifest’ file. Thanks for your feedback, Ludo’.
Ludovic Courtès <ludo@gnu.org> writes: > Hi, > > Pierre Neidhardt <mail@ambrevar.xyz> skribis: > >> Ludovic Courtès <ludo@gnu.org> writes: > > [...] > >>> • The generated files might use APIs that, in the meantime, got >>> deprecated or changed somehow. This is in contrast with >>> ‘--export-profile’, which interprets ‘manifest’ (a versioned file >>> format) and produces code that can use the API du jour. >> >> /run/current-system/configuration.scm suffers from the same problem. > > Not really because it’s precisely the file that you gave to build the > system. So you know you can run: > > cd /run/current-system > guix time-machine -C channels.scm -- system reconfigure configuration.scm > > and it’ll work (modulo the documented caveats). Ha, actually no, it won't always work! :) Configuration.scm is only the file passed to `guix system reconfigure`, but is this file inherits from other user Guile modules, then the configuration.scm won't be sufficient to regenerate the system. You could argue that it's a user problem, but still, there is an "impurity" here! :p > But again, that’s not really the goal here. The goal is to help users > willing to migrate from the “imperative” mode to the declarative mode. Sure, but my thinking is that we could hit two birds we one stone here. If we only think one half of the problem, we might end up with too many commands or an interface that's not flexible enough. > Once you’re using a manifest, probably you’ll want to put that under > version control, but that’s already the case. The channels.scm files are missing though. My two cents! :) Cheers!
Hi! So I went ahead and pushed this patch series as 15078567c17851ef0f2b017119f305e0d5e8a140. We can always improve from here, and hopefully getting actual user feedback will help us see the pros and cons of this option. Thanks! Ludo’.
Hi there! Here’s a simple but oft-requested feature (I remember discussing with Pierre and Simon a year ago at the Guix Days about ways to implement it—time flies!): these patches provide ‘guix package --export-manifest’ and ‘--export-channels’. These options spit a manifest and a channel spec, respectively, with the goal of helping users who wish to migrate to the declarative model. ‘--export-manifest’ honors transformations: if entries in the profile have associated transformations, those are preserved in the generated manifest. It also honors version specifiers (to some extent); for example, if you have guile@2.2 in your profile, it’ll put “guile@2.2” in the manifest, where “2.2” is the shortest prefix to disambiguate it from the other available versions of “guile”. ‘--export-channels’ does what you expect. When several commits of the same channel were used to build your profile, it picks the last one and adds the other one in a comment. There’s a catch though: it’s easy to get a large number of commits. For example, my main profile contains ~300 packages. I usually upgrade everything at once, so you’d expect to see a single commit for the ‘guix’ channel. But that’s not the case: when running ‘guix upgrade’, entries that do not need to be upgraded are left unchanged, and thus they carry their original commit. For my profile, the result is: --8<---------------cut here---------------start------------->8--- $ guix package --export-channels ;; This channel file can be passed to 'guix pull -C' or to ;; 'guix time-machine -C' to obtain the Guix revision that was ;; used to populate this profile. (list ;; Note: these other commits were also used to install some of the packages in this profile: ;; "458cb25b9e7e7c954f468023abea2bebb5d8c75b" ;; "4969b51d175497bfcc354c91803e9d70542b7113" ;; "3d85c3ec652feb22824f355538b51e6955ded361" ;; "3462678bc346c2f6ea81245d6842264b6dccd945" ;; "74eeb11daee906cb012f10b6bb3afd254f9ea5c2" ;; "e1f5c2292b88525414b5d0336a00bfa6741d4f14" ;; "3bdb2a026bc9d3967a31a2ccbcd670c018f85d3d" ;; "bf986c3e4325594c1c6a43cf0b67b92262842863" ;; "7607ace5091aea0157ba5c8a508129cc5fc4f931" ;; "98b89f432103b66efacee0bcba41a94148b8e870" ;; "7090159c23d6345992ab976d71fefeb1583cfcdf" ;; "c6872990b51971922f3064cba54ab752fcdc1559" ;; "6ee7468758d7c043692ae8c0b5e130fa4eabe94c" ;; "9744cc7b4636fafb772c94adb8f05961b5b39f16" ;; "d8feee9f18ede0d1ea4d0e4876f09a0dab770295" ;; "b76b1d3fb65fec98b96a2b4cfa984316dd956a29" (channel (name 'guix) (url "/home/ludo/src/guix") (commit "c6ca0fceb715340cfb2ba01bfec128aa8d385b92") (introduction (make-channel-introduction "9edb3f66fd807b096b48283debdcddccfea34bad" (openpgp-fingerprint "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA")))) ) --8<---------------cut here---------------end--------------->8--- The long commit list doesn’t look great, but in fact the chosen commit is almost certainly good enough. I looked into ‘guix package’ to see if we could update provenance data for manifest entries that are not upgraded because they’re already up-to-date (so that we end up with fewer different commits), and it’s tricky to do that, and maybe not desirable. So I left it at that. Anyway, for me the goal of these options is not “disassemble” the profile and provide its exact source code, but rather to help migrate to the declarative model. I think it does a good job at that. Thoughts? Ludo’. Ludovic Courtès (8): profiles: Add 'manifest->code'. utils: Add 'version-unique-prefix'. guix package: Add '--export-manifest'. channels: Factorize 'manifest-entry-channel' and channel serialization. channels: Add the channel name to channel sexps. guix describe: Use 'manifest-entry-channel'. channels: Add 'channel->code'. guix package: Add '--export-channels'. build-aux/build-self.scm | 3 + doc/guix.texi | 45 +++++++++++++ guix/build/profiles.scm | 6 +- guix/channels.scm | 134 ++++++++++++++++++++++++++------------ guix/describe.scm | 34 +++++++++- guix/profiles.scm | 86 +++++++++++++++++++++++- guix/scripts/describe.scm | 52 +++++---------- guix/scripts/package.scm | 118 ++++++++++++++++++++++++++++++++- guix/utils.scm | 35 +++++++++- tests/guix-package.sh | 10 ++- tests/profiles.scm | 30 ++++++++- tests/utils.scm | 8 ++- 12 files changed, 471 insertions(+), 90 deletions(-)