Re: how to "guix pack" a profile?
At this point, I am probably firmly in kOOk territory. :p For now I will stay silent on the issue until I have some concrete code to share. Thank you for sincerely engaging with me. Cheers, zimoun wrote: > On Fri, 19 Jun 2020 at 14:34, wrote: > > > > 1. Composable profiles, > > > > > > This is already possible. > > > > Would you kindly point me to the documentation? I am failing to find it. > > guix install hello -p foo > guix install emacs -p bar > eval $(guix package -p foo -p bar --search-paths=exact) > > So it composes. However maybe not what you had in mind. ;-) > > > By "composable profiles" what I have in mind is the sum of two existing > > profiles and extending them as necessary > > > > $ guix environment --with-profile saved-profiles/profile-A \ > >--with-profile saved-profiles/profile-B \ > > > > Yes, because "guix environment" cannot support "profile". As said, > IMHO you raised 2 interesting use cases: > > 1. create an environment based on a profile > 2. pack an existing profile > > Obviously "a profile" means the composition of profiles if any. > > > > I agree. If I'm to make any points, I should just submit some concrete > > patches. > > Patches are always welcome. :-) > > > Cheers, > simon > > ps: > Well, maybe we are falling in the "take it to private email" thread pattern. > ;-) > https://joeyh.name/blog/entry/thread_patterns/
Re: how to "guix pack" a profile?
Ludovic Courtès wrote: > Hi, > > zimoun skribis: > > > Ludo, WDYT about "guix pack -p profile" to generate a (relocatable) > > tarball or Docker image? I mean if it is not already possible. :-) > > That could work, but honestly I’d rather encourage -m. I’m not > convinced there’s a need for what you suggest here. > > Ludo’. The original proposal for this was to enable packing a development environment, as opposed to an --ad-hoc collection of packages. Am I simply missing how to do this? signature.asc Description: PGP signature
Policy to remove broken packages
Dear, After Guix Days 2019, the idea of having an informal policy to remove broken packages had emerged. Quoting the initial Björn's message [1]: > If a package is broken for more than 6 months, we should just > remove it from Guix. Prior to removing, we should announce on > the dev mailing list, maybe someone will care about it > then. If there is no response within 2 weeks, we really remove > it. And we all agreed. :-) How to make it happen? Where is the correct place to mark list them: Data Service or Cuirass? 1: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00019.html All the best, simon
Re: [OUTREACHY]: Integration of desktop environments into GNU Guix
@Danny Please find the attached patches. @Others Please find the following git log. commit a412459054b7ad00738dc66cb2035638f9c11b3c Author: Raghav Gururajan Date: Fri Jun 19 19:11:28 2020 -0400 gnu: gst-libav: Update package definition. * gnu/packages/gstreamer.scm (gst-libav): Update package definition. [arguments]<#:phases>['patch-docbook-xml]: New phase. [native-inputs]: Add docbook-xml, perl and ruby. [inputs]: Remove gst-plugins-base, orc and zlib. [propagated-inputs]: Add gstreamer and gst-plugins-base. [synopsis]: Modify. [description]: Modify. [license]: Change from gpl2+ to lgpl2.0+. commit 0109580032805d61700513aa5aee0891fed96b3c Author: Raghav Gururajan Date: Fri Jun 19 18:53:51 2020 -0400 gnu: gst-plugins-ugly: Update package definition. * gnu/packages/gstreamer.scm (gst-plugins-ugly): Update package definition. [arguments]<#:glib-or-gtk?>: New argument. <#:phases>['patch-docbook-xml]: New phase. ['pre-check]: New phase. [native-inputs]: Add docbook-xml, gettext-minimal, gsettings-desktop-schemas, perl and xorg-server-for-tests. [inputs]: Add glib, glib-networking and opencore-amr. Remove gst-plugins-base. [propagated-inputs]: Add gstreamer and gst-plugins-base. [synopsis]: Modify. [description]: Modify. commit 8d47e7bc65fa241e761e8a723a147f9c097f66d2 Author: Raghav Gururajan Date: Fri Jun 19 18:48:19 2020 -0400 gnu: gst-plugins-bad: Update package definition. * gnu/packages/gstreamer.scm (gst-plugins-base): Update package definition. [outputs]: New output 'doc'. [arguments]<#:glib-or-gtk?>: New argument. <#:phases>['patch-docbook-xml]: New phase. ['pre-check]: New phase. ['move-doc]: New phase. [native-inputs]: Add docbook-xml, gettext-minimal, gsettings-desktop-schemas, perl, libxml2 and xorg-server-for-tests. [inputs]: Add bzip2, cairo, ccextractor, chromaprint, directfb, faac, flite, glib, glib-networking, glu, gsm, iqa, lcms, libaom, libbs2b, libdc1394, libdca, libde265, libdrm, libexif, libfdk, libgme, libmfx, libmms, libmpcdec, libnice, libofa, libopenmpt, libtiff, libva, libx11, libxcb, libxext, libxshm, lilv, lv2, mjpegtools, nettle, opencv, openh264, openni2, pango, rtmpdump, sbc, sctp, spandsp, srt, svt-hevc, transcode, v4l-utils, vo-aacenc, vo-amrwbenc, vulkan-headers, vulkan-loader, webrtc-audio-processing, wildmidi, wpebackend-fdo, zbar and zxing-cpp. [propagated-inputs]: Add gstreamer and gst-plugins-base. [synopsis]: Modify. [description]: Modify. commit 5970d09c8db16c565ccdf9e3964829affdab2f6c Author: Raghav Gururajan Date: Thu Jun 18 21:05:20 2020 -0400 gnu: Add openni2. * gnu/packages/gstreamer.scm (openni2): New variable. commit f16e64e5afee6d70814cbf9b5730cb1b00f7589f Author: Raghav Gururajan Date: Thu Jun 18 20:38:35 2020 -0400 gnu: Add libnice. * gnu/packages/networking.scm (libnice): New variable. commit 3e032569d0dfe0b2f5b184b65f5534532abda5f3 Author: Raghav Gururajan Date: Thu Jun 18 12:33:53 2020 -0400 gnu: Add rtmpdump. * gnu/packages/networking.scm (rtmpdump): New variable. commit 4fdfc0999a8f16d563a6651875859973af798b1c Author: Raghav Gururajan Date: Thu Jun 18 12:29:16 2020 -0400 gnu: Add iqa. * gnu/packages/image.scm (iqa): New variable. commit bf481717c8a0b306c532eb5d3cc170c1581f4324 Author: Raghav Gururajan Date: Thu Jun 18 10:04:15 2020 -0400 gnu: Add zxing-cpp. * gnu/packages/aidc.scm (zxing-cpp): New variable. commit b34d5c89db9df4b63906e6b716610de4d423efe1 Author: Raghav Gururajan Date: Thu Jun 18 09:25:50 2020 -0400 gnu: Add wildmidi. * gnu/packages/audio.scm (wildmidi): New variable. commit 6dc93ef31c2ecca6618638a1d92c790c3bf9 Author: Raghav Gururajan Date: Thu Jun 18 06:55:01 2020 -0400 gnu: Add webrtc-audio-processing. * gnu/packages/audio.scm (webrtc-audio-processing): New variable. commit 3f49b0393cb26eb88fe9efc0f25853a3a62de36b Author: Raghav Gururajan Date: Thu Jun 18 06:14:20 2020 -0400 gnu: Add vo-aacenc. * gnu/packages/audio.scm (vo-aacenc): New variable. commit 9244d35ef12b4bd975f2bcd3a5e485aaa8bf7d20 Author: Raghav Gururajan Date: Wed Jun 17 16:50:58 2020 -0400 gnu: Add transcode. * gnu/packages/video.scm (transcode): New variable. commit fca9377762504f4fb70bc1427335dafbed4b0fe5 Author: Raghav Gururajan Date: Wed Jun 17 15:07:02 2020 -0400 gnu: Add tinyalsa. * gnu/packages/audio.scm (tinyalsa): New variable. commit 01e1f8eeb2688c960dfa861945bd4691e598f8b0 Author: Raghav Gururajan Date: Wed Jun 17 13:22:49 2020 -0400 gnu: Add svt-hevc. * gnu/packages/video.scm (svt-hevc): New variable. commit 3ba833d7d6bbed44cfb44429da56f84f6ba36cdf Author: Raghav Gururajan Date: Wed Jun 17 13:00:23 2020 -0400 gnu: Add srt. * gnu/packages/networking.scm (srt): New variable. commit
Re: Jami bug source investigation #4
Hello, it turns out there is a directory in libringclient package - include/libringclient/web-chatview and it contains the missing files, including the "web.gresource.xml" make and configure complain about. I need to copy the files from include/libringclient/web-chatview of libringclient package to source/web/ of jami package. How do I do this? I tried using modify-phases and just copying the files, but it fails in the same manner, while in the build directory obtained using "--keep-failed", there are only links to the files. Jan Wielkiewicz
Re: Change the '--with-source' flag to use the syntax `--with-source=PACKAGE=SOURCE`
> You can use ‘--with-source=PACKAGE=SOURCE’, too: > > https://guix.gnu.org/manual/en/html_node/Package-Transformation-Options.html Ah great, thanks!
Re: (propagated) 'inputs' depends on 'outputs'?
Hi Ludo,
On Fri, 19 Jun 2020 at 22:47, Ludovic Courtès wrote:
> zimoun skribis:
>> ;; For 'git-svn'.
>> ("subversion" ,subversion "svn")
>> ("perl-term-readkey" ,perl-term-readkey "svn")
> The ‘TODO’ file, which is really a museum, has this:
>
> ** extend ‘propagated-build-inputs’ with support for multiple outputs
>
> #+BEGIN_SRC scheme
> (outputs '("out" "include"))
> (propagated-build-inputs
> `"i1" ,p1 "o1")
> ("i2" ,p2))
>=> "include")
> ("i3" ,p3)))
> #+END_SRC
>
>
> Is this what you have in mind?
Yes. That's why it is important to go to museum. ;-)
But if the idea is old and has not happened yet, maybe it is not
worth... For Git, for sure! :-)
All the best,
simon
Re: backtrace when building os
Hi, Jan Synacek skribis: > $ cat guix-os.scm > (use-modules (gnu bootloader) >(gnu bootloader grub) >(gnu system file-systems)) > > (operating-system > (host-name "jsynacek-guix-os") > (timezone "Europe/Prague") > (locale "en_US.utf8") > (bootloader > (bootloader-configuration > (bootloader grub-efi-bootloader) > (target "/dev/sdx"))) > (file-systems > (list (file-system (mount-point "/home") >(device "/dev/sda33") >(type "ext4") This OS lacks a root file system (which is no excuse for throwing a backtrace, though!). Ludo’.
Re: Change the '--with-source' flag to use the syntax `--with-source=PACKAGE=SOURCE`
Hi, pkill9 skribis: > I propose changing the `--with-source` flag to use the syntax of > similar `--with-...` flags such as `--with-commit`, e.g. > `--with-source=PACKAGE=SOURCE`, because currently you need to > change a file to match the form "package-version.extension`, and it > searches the package graph to find the package to replace the input > with. It's annoying having to download a source file and change it's > filename just to have it work with this flag. You can use ‘--with-source=PACKAGE=SOURCE’, too: https://guix.gnu.org/manual/en/html_node/Package-Transformation-Options.html Ludo’.
Re: (propagated) 'inputs' depends on 'outputs'?
Hi,
zimoun skribis:
> I am not sure to get the point. From my understanding, it could be
> possible to add information to native-inputs, inputs and
> propagated-inputs, e.g.,
>
> ;; For 'git-svn'.
> ("subversion" ,subversion "svn")
> ("perl-term-readkey" ,perl-term-readkey "svn")
>
> or whatever other mean. Then it becomes possible to only build e.g.,
> git:svn and/or propagate specific inputs depending on the outputs.
The ‘TODO’ file, which is really a museum, has this:
** extend ‘propagated-build-inputs’ with support for multiple outputs
#+BEGIN_SRC scheme
(outputs '("out" "include"))
(propagated-build-inputs
`"i1" ,p1 "o1")
("i2" ,p2))
=> "include")
("i3" ,p3)))
#+END_SRC
Is this what you have in mind?
Ludo’.
Re: Latest download from website
Hi, Mathieu Othacehe skribis: >> That looks nice to me! I think it should prominently say that these are >> “development snapshots” (probably these two words must appear) though, >> and perhaps contain a link to /download for those looking for releases. >> >> Other than that, I’d say go for it! > > I took your remark into account and pushed. However, I missed > something. As the website is built as a derivation, there's no network > connection and the "latest-builds" request fails. > > ERROR: In procedure getaddrinfo: > In procedure getaddrinfo: Servname not supported for ai_socktype > building pages in '/tmp/gnu.org/software/guix'... > Backtrace: >2 (primitive-load "/gnu/store/k2r4jxc4jww15f05n3kndxrk0a4?") > In ice-9/eval.scm: > 619:8 1 (_ #f) > In guix/build/utils.scm: > 654:6 0 (invoke _ . _) > > Do you see a work-around? I missed something. Can’t we have a static page that refers to ci.guix.gnu.org/…/latest, and Cuirass returns a redirect from /latest to the actual URL? Thanks, Ludo’.
Re: generate commit messages for package updates
Hi, Ricardo Wurmus skribis: > Ludovic Courtès writes: > >> Pierre Neidhardt skribis: >> >>> Is it worth including in guix/etc? >> >> I think it’d be nice! > > I fixed a bug and added etc/committer.scm.in. Yay! Consider adding a line in “Contributing” to mention its existence. Thank you, Ludo’.
Re: how to "guix pack" a profile?
Hi,
elaexuo...@wilsonb.com skribis:
> What Pierre (and others?) initially proposed---what I am re-proposing---is
> that
> we put a blob of Guile into the profiles that is capable of uniquely and
> completely generating the profile where it resides.
What you propose is what ‘guix system reconfigure’ does: it produces
/run/current-system/{channels,configuration}.scm and you can reuse them
right away.
The different with ‘guix package’ is that ‘guix system’ supports nothing
but a declarative mode, so it’s easy to do the above.
Conversely, profiles can be managed “imperatively”. Thus, in the
general case, it’s not possible to write a ‘manifest.scm’ file
corresponding to a profile.
I hope this clarifies the situation.
Ludo’.
Re: how to "guix pack" a profile?
Hi, zimoun skribis: > Ludo, WDYT about "guix pack -p profile" to generate a (relocatable) > tarball or Docker image? I mean if it is not already possible. :-) That could work, but honestly I’d rather encourage -m. I’m not convinced there’s a need for what you suggest here. Ludo’.
Re: K of N trust in substitutes (related to reproducible builds)
Hi, Christopher Baines skribis: > Ludovic Courtès writes: > >>> 3: http://theworld.com/~cme/spki.txt >>> >>> Using the above ACL, you'd trust a substitute for a path with a specific >>> hash if you can find 2 narinfos for that path and hash if they're signed >>> with keys in that entry. Multiple entries would still be supported, and >>> you wouldn't need to specify the k-of-n bit if you don't want to. >>> >>> I'm not quite sure how expressive this is, or if there are some policies >>> that would be good to support that either can't be expressed, or can't >>> be expressed easily. There's probably other approaches, and how to >>> support trusting substitutes is an important part to consider. >> >> I would be tempted to not bake it into /etc/guix/acl. You would still >> authorize all the servers, but instead of choosing a policy that accepts >> anything signed by one of them, as is currently the case, you would >> choose a policy that only accepts something signed by two of them. >> >> The policy would be implemented in (guix scripts substitute). I haven’t >> put much thought into it but it could be something akin to >> ‘lookup-narinfos/diverse’, roughly. >> >> Thoughts? > > I think that could work, do you have any suggestions on how that "two" > would be configured? I guess it could be a boolean on/off, but it would > be probably more extensible to just allow providing a minimum number of > substitiute servers to agree. There should be a procedure that takes a list of narinfos signed with an authorized key and returns a Boolean. Then there can be a higher-order procedure returning a predicate, like: (make-ratio-predicate k n) The user-chosen predicate could live in /etc/guix/substitute-policy.scm or similar. Thanks, Ludo’.
Re: bug#35728: Tor & IceCat's TorButton shows it's connected but doesn't route the traffic
Mark H Weaver dixit (2020-06-18, 03:45): > Hello again. > > In my previous message, I asked: > > Which version of Debian did you test with, and how did you > > install the Firefox that you used for testing this? > > Also, what version of Firefox did you test with? Mark, That was more than a year ago, I cannot recall. I'm also not using Debian anymore so I cannot check it. Best regards, Marcin
Re: Release Guix 1.1.1?
On Thu, Jun 18, 2020 at 11:31:07PM +0200, zimoun wrote: > - What is the status of "alsa-lib cannot find its plugin"? The patch works (last time I tested a couple weeks ago) but I would really like a review of the C-language parts of the patch. signature.asc Description: PGP signature
Re: how to "guix pack" a profile?
On Fri, 19 Jun 2020 at 14:34, wrote: > > > 1. Composable profiles, > > > > This is already possible. > > Would you kindly point me to the documentation? I am failing to find it. guix install hello -p foo guix install emacs -p bar eval $(guix package -p foo -p bar --search-paths=exact) So it composes. However maybe not what you had in mind. ;-) > By "composable profiles" what I have in mind is the sum of two existing > profiles and extending them as necessary > > $ guix environment --with-profile saved-profiles/profile-A \ >--with-profile saved-profiles/profile-B \ > Yes, because "guix environment" cannot support "profile". As said, IMHO you raised 2 interesting use cases: 1. create an environment based on a profile 2. pack an existing profile Obviously "a profile" means the composition of profiles if any. > I agree. If I'm to make any points, I should just submit some concrete > patches. Patches are always welcome. :-) Cheers, simon ps: Well, maybe we are falling in the "take it to private email" thread pattern. ;-) https://joeyh.name/blog/entry/thread_patterns/
Re: “Reproducible research articles, from source code to PDF”
zimoun skribis: > On Fri, 19 Jun 2020 at 14:04, Ludovic Courtès > wrote: > >> I’d happily defer to Simon; Simon, would you be able to organize this? > > Yesterday evening, I have sent an email to guix-hpc with the subject: > "Let sync Hackathon reproducible and past" for this purpose. :-) > Is this email lost? Or somehow blocked? Let me know? Oh great, let me check mail… Ludo’.
Re: how to "guix pack" a profile?
> > 1. Composable profiles, > > This is already possible. Would you kindly point me to the documentation? I am failing to find it. By "composable profiles" what I have in mind is the sum of two existing profiles and extending them as necessary $ guix environment --with-profile saved-profiles/profile-A \ --with-profile saved-profiles/profile-B \ > This snippet of quotation shows that it is not "easy" for the general > case. And the transformation using "--load-path" has not been evoked. > For example: > > --8<---cut here---start->8--- > (define-module (foo) > #:use-module (guix packages) > #:use-module (guix profiles) ;; imagine it is used > #:use-module (gnu packages base)) > > (define (crazy-transformation pkg) > "Could do really complicated things" > (package > (inherit pkg) > (name (string-append "ex-" (package-name pkg) > > (define bonjour > (package > (inherit hello) > (name "bonjour"))) > > (define-public crazy-bonjour > (crazy-transformation bonjour)) > --8<---cut here---end--->8--- > > then "guix install -L /path/to/foo ex-bonjour". Thank you for the concrete example. I guess it wasn't clear in my previous emails, but I proposed *simply copying /path/to/foo* into the generated profile and letting "manifest.scm" refer to these copies. Is this obviously broken. > Thank you for the ideas. Especially the two ones: > > 1. create an environment from a profile > 2. pack a profile > > Well, I do not know if they will happen but it should be cool to have. I agree. If I'm to make any points, I should just submit some concrete patches. Again, thank you for your time and patience. Cheers, signature.asc Description: PGP signature
Re: how to "guix pack" a profile?
> I am not sure we are talking about the same channels.scm file. I guess, > you have in mind ~/.config/guix/channels.scm but it is not the one of > interest for reproducing. You need the real one, i.e., "guix describe > -f channels". > > AFAIU, manifest.scm+$(guix describe -f channel) is enough to have > "deterministic profile (re)generation". If not, it means there is a > "bug" in Inferiors or I miss something. Bingo! This is exactly what I was missing. Thank you for sifting this out. Given the stated "goal of ... [allowing] users to move towards declarative 'manifest.scm' style..." I completely mis-interpreted the sense in which you were using "channels.scm". signature.asc Description: PGP signature
Re: “Reproducible research articles, from source code to PDF”
On Fri, 19 Jun 2020 at 14:04, Ludovic Courtès wrote: > I’d happily defer to Simon; Simon, would you be able to organize this? Yesterday evening, I have sent an email to guix-hpc with the subject: "Let sync Hackathon reproducible and past" for this purpose. :-) Is this email lost? Or somehow blocked? Let me know? Well, I do not know if I would be able to organize but I can do my best. :-) > I guess we don’t need much actually: a date, an IRC channel, and > perhaps a web page on hpc.guix.info announcing the event so others can > join. The email mentioned above asks exactly that: first pick a date. And for the sake of archive, I started another thread. Cheers, simon
Re: “Reproducible research articles, from source code to PDF”
Hi, Konrad Hinsen skribis: > Ludovic Courtès writes: > >>> Maybe we could organize a Virtual Hackathon? Over 1 day? Or 2 days? >>> The power of collective motivation. :-) >> >> Sounds like a good idea! Perhaps a one-day hackathon to begin with? >> Early July maybe? > > Sounds fine. I am not much of a hackathon expert, so I don't propose > myself for organizing this, but I can make a preselection of suitable > submissions to the ReScience challenge (no proprietary software etc.) > with comments about the specific challenges. I’d happily defer to Simon; Simon, would you be able to organize this? I guess we don’t need much actually: a date, an IRC channel, and perhaps a web page on hpc.guix.info announcing the event so others can join. Ludo’.
Re: how to "guix pack" a profile?
On Fri, 19 Jun 2020 at 11:52, elaexuo...@wilsonb.com wrote: > You emphasize that declarative package management with "manifest.scm" is the > way to go. I agree but wanted to point out that > > $ guix package -m manifest.scm > > produces a different /gnu/store/-profile, depending on when it's run (or > more precisely, depending on which channel commits guix resolves for the > invocation). Yes, but AFAIU the correct is: guix describe -f channels > channel.scm guix package -m manifest.scm then later or elsewhere, reproduce with: guix time-machine -C channel.scm -- package -m manifest.scm > You know that, of course, but the point I try to make is that "manifest.scm" > and "channels.scm" are *not enough* to uniquely determine a specific > /gnu/store/-profile. We need to separate out the concepts of > "declarative > profile management" and "deterministic profile regeneration." Do you have examples? I am not sure we are talking about the same channels.scm file. I guess, you have in mind ~/.config/guix/channels.scm but it is not the one of interest for reproducing. You need the real one, i.e., "guix describe -f channels". AFAIU, manifest.scm+$(guix describe -f channel) is enough to have "deterministic profile (re)generation". If not, it means there is a "bug" in Inferiors or I miss something. All the best, simon
Re: how to "guix pack" a profile?
zimoun, Thank you for you time. Apparently, I am indeed missing some important conceptual details. I will come back later when I know more. Cheers and happy Guixing, zimoun wrote: > Dear, > > On Fri, 19 Jun 2020 at 11:52, elaexuo...@wilsonb.com wrote: > > > What Pierre (and others?) initially proposed---what I am > > re-proposing---is that we put a blob of Guile into the profiles that > > is capable of uniquely and completely generating the profile where it > > resides. > > Others? For example me. With Pierre, we spent some time at Guix Days > to propose a new format. > > > 1. Composable profiles, > > This is already possible. > > > 2. Sharing "light" profiles buy sending only the "recipe.scm" instead > > of an entire container. > > I am not sure to get what is a "light" profile but from my understanding > what you want here already exist and it is manifest.scm+channel.scm. > > > 3. guix archive --manifest > > 4. guix profile --manifest-from-recipe /recipe.scm > > > > The last one there is intended to be the tool for "migrate from > > imperative to declarative" user profile management, starting from a > > given profile. > > See below. > > >> What you describe here is exactly what Pierre and other have > >> proposed. And the work-to-do is to prototype the format of what you > >> called "recipe.scm", which means equivalently in the previous emails > >> change the format of /manifest. > > > > I agree. However, in previous emails I have tried to make a rebuttal > > to Ludo's argument than the best we can do is *approximate* a > > manifest.scm. > > > > See https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00098.html: > > I have the impression that the discussion is going nowhere. > > Make what you called "recipe.scm" or modify " become an acceptable "--manifest" is doable. Note that the idea is not > new either. As I said, all the technical material is here. But Ludo > and others (me) are not convinced that it will pay off because the > general case is hard. Well, to be concrete, there are 2 possible next > actions: > > a) prototype the new format and implement it > b) make an approximation exposed with "--export" > > Frankly, I doubt that a) happens because no one will do the tough work. > Therefore, b) is pragmatic. > > > (Ludo) > As far as faithfulness is concerned, we should also keep in mind > that we don’t always have all the information needed to reconstruct > what’s in a profile. For example, we lack information about the > package transformation options that were used (if any), > >>> > >>> (Pierre) > >>> Like `--with-input'? I didn't think of this. Can't we extend the > >>> format then to include all transformation options, with future-proof > >>> provisions? > >> > >> (Ludo) > >> We couldstore package transformations as manifest entry properties. > >> > >> However, that’ll be an approximation: the exact implementation of > >> ‘--with-input’, for instance, can vary over time. > > This snippet of quotation shows that it is not "easy" for the general > case. And the transformation using "--load-path" has not been evoked. > For example: > > --8<---cut here---start->8--- > (define-module (foo) > #:use-module (guix packages) > #:use-module (guix profiles) ;; imagine it is used > #:use-module (gnu packages base)) > > (define (crazy-transformation pkg) > "Could do really complicated things" > (package > (inherit pkg) > (name (string-append "ex-" (package-name pkg) > > (define bonjour > (package > (inherit hello) > (name "bonjour"))) > > (define-public crazy-bonjour > (crazy-transformation bonjour)) > --8<---cut here---end--->8--- > > then "guix install -L /path/to/foo ex-bonjour". > > > > However, with `time-machine' and a given `guix environment' or `guix > > profile' invocation, we are able to deterministically resolve a > > /gnu/store/-profile, no? Better yet, this is in a future-proof > > way, no? If that is so, then why not canonify this profile recipe in > > guile code instead of what is needed now: guile + bash? What am I > > missing here? > > You are missing the difficulty to make it concretely, I guess. :-) > > > > Just to be clear, I would be more than thrilled with a --from-profile > > option to `guix pack'. However, I am trying to make a case that "first > > class profiles" is both feasible and may pay back more in maintenance > > cost than it consumes. > > Thank you for the ideas. Especially the two ones: > > 1. create an environment from a profile > 2. pack a profile > > Well, I do not know if they will happen but it should be cool to have. > > > I am going to move on since we already raised all the points, I guess. :-) > > > All the best, > simon signature.asc Description: PGP signature
Re: how to "guix pack" a profile?
Dear, On Fri, 19 Jun 2020 at 11:52, elaexuo...@wilsonb.com wrote: > What Pierre (and others?) initially proposed---what I am > re-proposing---is that we put a blob of Guile into the profiles that > is capable of uniquely and completely generating the profile where it > resides. Others? For example me. With Pierre, we spent some time at Guix Days to propose a new format. > 1. Composable profiles, This is already possible. > 2. Sharing "light" profiles buy sending only the "recipe.scm" instead > of an entire container. I am not sure to get what is a "light" profile but from my understanding what you want here already exist and it is manifest.scm+channel.scm. > 3. guix archive --manifest > 4. guix profile --manifest-from-recipe /recipe.scm > > The last one there is intended to be the tool for "migrate from > imperative to declarative" user profile management, starting from a > given profile. See below. >> What you describe here is exactly what Pierre and other have >> proposed. And the work-to-do is to prototype the format of what you >> called "recipe.scm", which means equivalently in the previous emails >> change the format of /manifest. > > I agree. However, in previous emails I have tried to make a rebuttal > to Ludo's argument than the best we can do is *approximate* a > manifest.scm. > > See https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00098.html: I have the impression that the discussion is going nowhere. Make what you called "recipe.scm" or modify ">>> (Ludo) As far as faithfulness is concerned, we should also keep in mind that we don’t always have all the information needed to reconstruct what’s in a profile. For example, we lack information about the package transformation options that were used (if any), >>> >>> (Pierre) >>> Like `--with-input'? I didn't think of this. Can't we extend the >>> format then to include all transformation options, with future-proof >>> provisions? >> >> (Ludo) >> We couldstore package transformations as manifest entry properties. >> >> However, that’ll be an approximation: the exact implementation of >> ‘--with-input’, for instance, can vary over time. This snippet of quotation shows that it is not "easy" for the general case. And the transformation using "--load-path" has not been evoked. For example: --8<---cut here---start->8--- (define-module (foo) #:use-module (guix packages) #:use-module (guix profiles) ;; imagine it is used #:use-module (gnu packages base)) (define (crazy-transformation pkg) "Could do really complicated things" (package (inherit pkg) (name (string-append "ex-" (package-name pkg) (define bonjour (package (inherit hello) (name "bonjour"))) (define-public crazy-bonjour (crazy-transformation bonjour)) --8<---cut here---end--->8--- then "guix install -L /path/to/foo ex-bonjour". > However, with `time-machine' and a given `guix environment' or `guix > profile' invocation, we are able to deterministically resolve a > /gnu/store/-profile, no? Better yet, this is in a future-proof > way, no? If that is so, then why not canonify this profile recipe in > guile code instead of what is needed now: guile + bash? What am I > missing here? You are missing the difficulty to make it concretely, I guess. :-) > Just to be clear, I would be more than thrilled with a --from-profile > option to `guix pack'. However, I am trying to make a case that "first > class profiles" is both feasible and may pay back more in maintenance > cost than it consumes. Thank you for the ideas. Especially the two ones: 1. create an environment from a profile 2. pack a profile Well, I do not know if they will happen but it should be cool to have. I am going to move on since we already raised all the points, I guess. :-) All the best, simon
