IRC channel logs


back to list of logs

<zimoun>Reading civodul re-toot from Lennart Poettering, I ended on “All Systems Go!” … argh when evil Internet leads to interesting talks. ;-)
<zimoun>Fast, correct, reproducible builds with Nix + Bazel
<zimoun>By Tweag people.
<rekado>zimoun: do you happen to still have materials for the past workshops you ran to introduce Guix?
<rekado>I’m trying to prepare for the workshop next week, but I don’t really know how best to fill 3 hours without boring people.
<zimoun>rekado: French video
<zimoun>Here examples with Julia and attendees run with Python
<zimoun>The idea was a fake paper:
<zimoun>And let redo Figure 1.
<zimoun>Where I provide Julia script.
<zimoun>And where I also provide Python script.
<zimoun>And somewhow, we demo with one and attendees exercise with the other.
<rekado>ah, interesting
<rekado>I think my target audience differs a little
<rekado>no scientists but sysadmins
<zimoun>All is simple but keep the essentials for touching what Guix provides.
<zimoun>For sysadmins, I have never prepared materials.
<rekado>I’ll have to think about this for some time.
<rekado>I’d really like to get the participants to feel somewhat comfortable with “guix shell” and “guix system”, and to have them set up a channel and contribute one package to Guix.
<zimoun>Somehow, the question is: after these 3h, what do they get back for home? How to run Guix on infra? How to package stuff? etc.
<zimoun>Ah you just answered my question :-)
<rekado>I want them to become sensitized to what Guix users would do, and how they can support these use cases.
<rekado>with regards to channels or custom package definitions I found that there’s still quite a bit of boilerplate that we need to get started.
<rekado>importing the build system module, the license module, modules for all inputs…
<rekado>it’s a bit tedious
<rekado>more generally, I wonder if modularization of gnu/packages/* actually makes a lot of sense in Guix
<rekado>we rarely ever have duplicate variable definitions
<zimoun>Well, before going to plumbing as make a package etc., maybe an example as deploy a tiny website with “guix shell“, then containerized with ‘guix shell -CN’ then write a config.scm for a VM and deploy the website.
<rekado>yes, small examples with big results are a good way to get started
<rekado>still worried about all the drudgery of finding modules and fixing syntax errors…
<rekado>manifests have a similar problem
<rekado>specifications->manifest looks simple enough, but when you want to modify a package in any way you deal with package objects
<rekado>and then you can’t use specifications->manifest any more
<rekado>even if the specification matches a definition in the same file.
<zimoun>Yeah, I agree.
<zimoun>From my point of view, pedagocially speaking, if I need to tweak the package object, then I first go via ‘guix search’ and ‘guix show’ and explain the module via the location field. It is far to be best but it provides a good rule of thumb which avoids many unrelated questions.
<zimoun>I do not speak about specification->manifest.
<rekado>I do the same.
<rekado>and I like to show package transformations
<rekado>but as soon as we’re moving from the command line to a manifest package transformations become a little tricky to use.
<zimoun>yeah, I agree. Although options->transformation applies on package object and the UI is very close to command-line one.
<civodul>what i recommend is coming up with a command-line that works (incl. transformations), and then using ‘--export-manifest’ on that
<civodul>the manifest includes transformations so it’s easier to work from there
<civodul>makes manifests less scary