Re: Dissecting Guix -- blog post series
Heya, On Mon Dec 12, 2022 at 1:43 AM GMT, Mekeor Melire wrote: > Or auto-fill-mode? :) I'm pretty new to Emacs, so I dunno which way is best -.o.- > Personally, I felt kind of fooled at that point, because it felt > like I had made needless efforts to read an irrelevant code > snippet. Fair enough, but I also think if I remove it people will be left wondering how ``recursive?'' is serialised. I think that code snippet might be irrelevant anyway, since I can just show the result of serialising a derivation with ``recursive? #t''. > By the way, sorry for the malformatted e-mail; I was tweaking > around with my mail-client's settings. (I'm now using f=f and > non-broken lines.) Hope my mails are well readable at your end. > Please let me know if they're not. They're perfectly readable, but the lines are quite short. -- ( signature.asc Description: PGP signature
Re: Dissecting Guix -- blog post series
Hi, On +2022-12-09 17:25:35 +, ( wrote: > Heya, > > On Fri Dec 9, 2022 at 9:32 AM GMT, wrote: > > How does a gullible noob like me know what the dangers might be, (e.g. > > http:) > > and how to avoid (most of) them by finding a guix version that has been > > gone through with a fine-tooth comb by trusted guix devs and has been > > re-hosted at gitlab or gnu.org, etc ... for added security? > > Sorry, I don't really understand; how is this relevant to derivations? :) > > -- ( Maybe I mis-imagine your assumptions about your audience. For myself, I would like an emacs M-x idiot-mode so I could run a boot-bricker-test.sh script someone has posted, without worrying that in plain cli context, it will /actually/ brick my machine :) I am assuming if your lowlevel examples are really good, they will be used as bases for cut/paste variants that people will then post and implicitly prompt each other to try.. I don't trust that everything thus posted will be both benevolent and competently avoiding security vulns. I can't even trust my own stuff. I make too many mistakes :) So, narrowly focusing on derivations, maybe trust is not technically relevant, but in the larger social context gullible noobs like me need all the help we can get about recognizing potentially dangerous code. And I think derivations can potentially contain or generate or activate code one should not trust. So that's how I see asking for trust info being relevant to derivations :) -- Regards, Bengt Richter
Re: Dissecting Guix -- blog post series
2022-12-11 10:08 pa...@disroot.org: On Sat Dec 10, 2022 at 9:25 PM GMT, Mekeor Melire wrote: > By the way, the text does not seem to strictly fill columns at > a certain line width. So I did not bother to fill columns in > the "patch". Right, I should set up FILL-COLUMNS-INDICATOR... :) Or auto-fill-mode? :) > If the purpose is out of scope, then we should not dive in > that deeply. Especially, I'd suggest skip the code snippet. I'm not sure about this. Personally, I felt kind of fooled at that point, because it felt like I had made needless efforts to read an irrelevant code snippet. > I think an example for invoking read-derivation-from-file > would round up this tutorial really nicely because it'd close > the circle between .drv-files and -objects. Okay! And one for write-derivation, too. Sure :) By the way, sorry for the malformatted e-mail; I was tweaking around with my mail-client's settings. (I'm now using f=f and non-broken lines.) Hope my mails are well readable at your end. Please let me know if they're not.
Re: Dissecting Guix -- blog post series
Heya, On Sat Dec 10, 2022 at 9:25 PM GMT, Mekeor Melire wrote: > I think it'd also be fine to come up with the titles during the process of > writing as sometimes that process itself is insightful. E.g. I could imagine > parts 2 and 4 to collapse. Maybe, maybe not, you'll see. Perhaps. I think monads are complex enough to warrant their own post, though. > How'd this part differ from section "12.18 Defining Services" of the manual? Along with a low-level description of the workings of services, it'd contain a complex, concrete example of a service. The manual mostly has an API reference and some high-level-ish examples. > How'd this part differ from sections 22 and "22.6 Submitting Patches" from > the manual? Again, it'd be more concrete than what the manual shows. It'd explain the process by demonstrating the development of an *actual patch*, and showing how it could be sent to guix-patc...@gnu.org. > By the way, the text does not seem to strictly fill columns at a certain line > width. So I did not bother to fill columns in the "patch". Right, I should set up FILL-COLUMNS-INDICATOR... :) > If the purpose is out of scope, then we should not dive in that deeply. > Especially, I'd suggest skip the code snippet. I'm not sure about this. > Here you write "pretty simple". Later you also write "self-explanatory" and > "obviously". I suggest to let the reader decide what's simple. Fair. > Before this point, the record fields have been called '"argument"'s all the > time. I think it's not nice style to carry on a quoted term through many > paragraphs like this. Let's simply write "record field" all the time, instead. This is fair too :) > I think an example for invoking read-derivation-from-file would round up this > tutorial really nicely because it'd close the circle between .drv-files and > -objects. Okay! And one for write-derivation, too. > Here, in the conclusion, IMHO, there could be another brief listing of all > fields of a derivation. Good idea. -- ( signature.asc Description: PGP signature
Re: Dissecting Guix -- blog post series
2022-12-08 18:24 pa...@disroot.org: > Some of you may have seen on IRC that I've been writing a post for the Guix > blog that I hope will form the first part of a series. This series aims to > dissect the internals of Guix, from bottom to top. Great, I'm looking forward to read it! Especially, personally, I'm eager for the rather fundamental concepts of Guix (and Nix). > Perhaps they could go in the cookbook once the series is done? Yes, I personally think the content should be published at two places at the same time: OTOH, it should either be incorporated into either the manual or the cookbook; and OTOH, it should be published as a blog-post. The blog-post should also link to the respective section of the manual or cookbook in a preamble. > * Dissecting Guix, Part 1: Derivations > * Dissecting Guix, Part 2: The Humble G-Expression > * Dissecting Guix, Part 3: Packages > * Dissecting Guix, Part 4: Monads > * Dissecting Guix, Part 5: Profiles and Search Paths > * Dissecting Guix, Part 6: Goings-On in the Build Container > * Dissecting Guix, Part 7: Record Types > * Dissecting Guix, Part 8: Substitutes and Grafts > * Dissecting Guix, Part 9: Cross-Compilation I think it'd also be fine to come up with the titles during the process of writing as sometimes that process itself is insightful. E.g. I could imagine parts 2 and 4 to collapse. Maybe, maybe not, you'll see. > * Dissecting Guix, Part 10: Services > > Walks you through the process of creating a service, and thouroughly explains > system configuration. How'd this part differ from section "12.18 Defining Services" of the manual? > * Dissecting Guix, Part 11: Home Services > * Dissecting Guix, Part 12: Writing a Subcommand > * Dissecting Guix, Part 13: Lending a Hand > > How to edit the Guix source code and submit patches to be reviewed by the > lovely Guix community! How'd this part differ from sections 22 and "22.6 Submitting Patches" from the manual? Now, as for the actual article. Firstly, I added some comments below. Secondly, I created a "patch" suggesting some changes. By the way, the text does not seem to strictly fill columns at a certain line width. So I did not bother to fill columns in the "patch". > title: Dissecting Guix, Part 1: Derivations and Derivation > date: TBC > author: ( > tags: Dissecting Guix, Functional package management, Programming interfaces, > Scheme API > --- > To a new user, Guix's functional architecture can seem quite alien, and > possibly offputting. With a combination of extensive `#guix`-querying, > determined manual-reading, and plenty of source-perusing, they may > eventually figure out how everything fits together by themselves, but this > can be frustrating and often takes a fairly long time. > > However, once you peel back the layers, the "Nix way" is actually rather > elegant, if perhaps not as simple as the mutable, imperative style > implemented by the likes of [`dpkg`](https://wiki.debian.org/dpkg) and, > [`pacman`](https://wiki.archlinux.org/title/pacman). This series of blog > posts will cover basic Guix concepts, taking a "ground-up" approach by > dealing with lower-level concepts first, and hopefully make those months of > information-gathering unnecessary. > > Before we dig in to Guix-specific concepts, we'll need to learn about one > inherited from [Nix](https://nixos.org), the original functional package > manager and the inspiration for Guix; the idea of a _derivation_ and its > corresponding _store items_. > > These concepts were originally described by Eelco Dolstra, the author of Nix, > in their [PhD thesis](https://edolstra.github.io/pubs/phd-thesis.pdf); see > _§ 2.1 The Nix store_ and _§ 2.4 Store Derivations_. > > # Store Items > > As you almost certainly know, everything that Guix builds is stored in the > _store_, which is almost always the `/gnu/store` directory. It's the job of > the > [`guix-daemon`](https://guix.gnu.org/manual/en/html_node/Invoking-guix_002ddaemon.html) > to manage the store and build things. If you run > [`guix build > PKG`](https://guix.gnu.org/manual/en/html_node/Invoking-guix-build.html), > `PKG` will be built or downloaded from a substitute server if available, and > a path to an item in the store will be displayed. > > ``` > $ guix build irssi > /gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3 > ``` > > This item contains the final result of building [`irssi`](https://irssi.org). > Let's peek inside: > > ``` > $ ls $(guix build irssi) > bin/ etc/ include/ lib/ share/ > $ ls $(guix build irssi)/bin > irssi* > ``` > > `irssi` is quite a simple package. What about a more complex one, like > [`glib`](https://docs.gtk.org/glib)? > > ``` > $ guix build glib > /gnu/store/bx8qq76idlmjrlqf1faslsq6zjc6f426-glib-2.73.3-bin > /gnu/store/j65bhqwr7qq7l77nj0ahmk1f1ilnjr3a-glib-2.73.3-debug > /gnu/store/3pn4ll6qakgfvfpc4mw89qrrbsgj3jf3-glib-2.73.3-doc > /gnu/store/dvsk6x7d26nmwsqhnzws4iirb6dhhr1d-glib-2.73.3 >
Re: Dissecting Guix -- blog post series
Heya, On Fri Dec 9, 2022 at 9:32 AM GMT, wrote: > How does a gullible noob like me know what the dangers might be, (e.g. http:) > and how to avoid (most of) them by finding a guix version that has been > gone through with a fine-tooth comb by trusted guix devs and has been > re-hosted at gitlab or gnu.org, etc ... for added security? Sorry, I don't really understand; how is this relevant to derivations? :) -- ( signature.asc Description: PGP signature
Re: Dissecting Guix -- blog post series
Hi, On +2022-12-09 07:33:16 +, ( wrote: > On Fri Dec 9, 2022 at 7:31 AM GMT, 宋文武 wrote: > > I think it's missing what "build-derivations" do, or "Part 0: Store". > > Hmm, do you mean adding an example of building a derivation in Scheme with > ``build-derivations''? I'll definitiely add that :) > > -- ( Where is a "What can I trust?" section? I.e., when some well-meaning enthusiast says, --8<---cut here---start->8--- "Can we package the "warm-fuzzy-floss-name" package that they have at http://www.lesser-known-but-nice-sounding-distro.org/fantabulous/; --8<---cut here---end--->8--- How does a gullible noob like me know what the dangers might be, (e.g. http:) and how to avoid (most of) them by finding a guix version that has been gone through with a fine-tooth comb by trusted guix devs and has been re-hosted at gitlab or gnu.org, etc ... for added security? -- Regards, Bengt Richter
Re: Dissecting Guix -- blog post series
On Fri Dec 9, 2022 at 7:31 AM GMT, 宋文武 wrote: > I think it's missing what "build-derivations" do, or "Part 0: Store". Hmm, do you mean adding an example of building a derivation in Scheme with ``build-derivations''? I'll definitiely add that :) -- ( signature.asc Description: PGP signature
Re: Dissecting Guix -- blog post series
"(" writes:
> Heya!
>
> Some of you may have seen on IRC that I've been writing a post for the Guix
> blog that I hope will form the first part of a series. This series aims to
> dissect the internals of Guix, from bottom to top. Perhaps they could go in
> the cookbook once the series is done? My aim is to write the following posts
> (complete with cheesy titles :P), hopefully one per week:
>
> * Dissecting Guix, Part 1: Derivations
>
> Discusses derivations, the bottom layer of the Guix compilation tower, and
> dissects some example derivations.
>
> A draft of this post may be found below. Please feel free to critique! :)
Great, thank you!
I think it's missing what "build-derivations" do, or "Part 0: Store".
Dissecting Guix -- blog post series
Heya! Some of you may have seen on IRC that I've been writing a post for the Guix blog that I hope will form the first part of a series. This series aims to dissect the internals of Guix, from bottom to top. Perhaps they could go in the cookbook once the series is done? My aim is to write the following posts (complete with cheesy titles :P), hopefully one per week: * Dissecting Guix, Part 1: Derivations Discusses derivations, the bottom layer of the Guix compilation tower, and dissects some example derivations. A draft of this post may be found below. Please feel free to critique! :) * Dissecting Guix, Part 2: The Humble G-Expression Talks about g-expressions and why they're necessary, explains file-like objects, and provides demonstrations of each kind of file-like. * Dissecting Guix, Part 3: Packages A walkthrough for package creation. * Dissecting Guix, Part 4: Monads ``mlet'', ``>>='', ``define-monad'', ``return'', and all that. * Dissecting Guix, Part 5: Profiles and Search Paths Explores profiles and search paths. * Dissecting Guix, Part 6: Goings-On in the Build Container Explains build systems, examines a build script, and talks about what exactly happens when a package is built. Also demonstrates some of the ``(guix build utils)'' APIs. * Dissecting Guix, Part 7: Record Types Demonstrates the ``(guix records)'' API in all its glory. * Dissecting Guix, Part 8: Substitutes and Grafts Discusses substitutes, and that persistent thorn in our sides, grafting. * Dissecting Guix, Part 9: Cross-Compilation Building packages on architecture X for architecture Y, and how that all works. * Dissecting Guix, Part 10: Services Walks you through the process of creating a service, and thouroughly explains system configuration. * Dissecting Guix, Part 11: Home Services Similar to Part 9, except it's about ``guix home'', of course. * Dissecting Guix, Part 12: Writing a Subcommand Guides you through the process of adding a new command to Guix with the extensions feature, demonstrating several utility APIs in the process. * Dissecting Guix, Part 13: Lending a Hand How to edit the Guix source code and submit patches to be reviewed by the lovely Guix community! -- ( title: Dissecting Guix, Part 1: Derivations and Derivation date: TBC author: ( tags: Dissecting Guix, Functional package management, Programming interfaces, Scheme API --- To a new user, Guix's functional architecture can seem quite alien, and possibly offputting. With a combination of extensive `#guix`-querying, determined manual-reading, and plenty of source-perusing, they may eventually figure out how everything fits together by themselves, but this can be frustrating and often takes a fairly long time. However, once you peel back the layers, the "Nix way" is actually rather elegant, if perhaps not as simple as the mutable, imperative style implemented by the likes of [`dpkg`](https://wiki.debian.org/dpkg) and, [`pacman`](https://wiki.archlinux.org/title/pacman). This series of blog posts will cover basic Guix concepts, taking a "ground-up" approach by dealing with lower-level concepts first, and hopefully make those months of information-gathering unnecessary. Before we dig in to Guix-specific concepts, we'll need to learn about one inherited from [Nix](https://nixos.org), the original functional package manager and the inspiration for Guix; the idea of a _derivation_ and its corresponding _store items_. These concepts were originally described by Eelco Dolstra, the author of Nix, in their [PhD thesis](https://edolstra.github.io/pubs/phd-thesis.pdf); see _§ 2.1 The Nix store_ and _§ 2.4 Store Derivations_. # Store Items As you almost certainly know, everything that Guix builds is stored in the _store_, which is almost always the `/gnu/store` directory. It's the job of the [`guix-daemon`](https://guix.gnu.org/manual/en/html_node/Invoking-guix_002ddaemon.html) to manage the store and build things. If you run [`guix build PKG`](https://guix.gnu.org/manual/en/html_node/Invoking-guix-build.html), `PKG` will be built or downloaded from a substitute server if available, and a path to an item in the store will be displayed. ``` $ guix build irssi /gnu/store/v5pd69j3hjs1fck4b5p9hd91wc8yf5qx-irssi-1.4.3 ``` This item contains the final result of building [`irssi`](https://irssi.org). Let's peek inside: ``` $ ls $(guix build irssi) bin/ etc/ include/ lib/ share/ $ ls $(guix build irssi)/bin irssi* ``` `irssi` is quite a simple package. What about a more complex one, like [`glib`](https://docs.gtk.org/glib)? ``` $ guix build glib /gnu/store/bx8qq76idlmjrlqf1faslsq6zjc6f426-glib-2.73.3-bin /gnu/store/j65bhqwr7qq7l77nj0ahmk1f1ilnjr3a-glib-2.73.3-debug /gnu/store/3pn4ll6qakgfvfpc4mw89qrrbsgj3jf3-glib-2.73.3-doc /gnu/store/dvsk6x7d26nmwsqhnzws4iirb6dhhr1d-glib-2.73.3 /gnu/store/4c8ycz501n2d0xdi4blahvnbjhd5hpa8-glib-2.73.3-static ``` `glib` produces five `/gnu/store` items, because it's possible for a package
