Am Samstag, dem 08.10.2022 um 10:35 +0200 schrieb zimoun:
Toggle quote (21 lines)
> Hi Liliana,
>
> What are we discussing if we are agreeing? ;-)
>
> Well, from my understanding, we are miscommunicating and somehow just
> saying the same thing using a different point of view.
>
>
> On Fri, 07 Oct 2022 at 21:28, Liliana Marie Prikler
> <liliana.prikler@gmail.com> wrote:
> > Am Freitag, dem 07.10.2022 um 20:49 +0200 schrieb zimoun:
>
> > > Let start to have a simple extension that we can improve by
> > > incremental changes,
> >
> > My point is that we already have proper extensions in both guix and
> > other channels. It's a little late to "start with a simple [one]".
>
> What others do I miss? I am only aware of gwl and guix-modules.
>
> What are the other extensions and from which channels?
Oh, guix-modules is included in Guix proper. I thought it was part of
an HPC channel, my bad.
Toggle quote (14 lines)
> > > The already included extension 'guix-modules' is usable using the
> > > snippet above. And we teach people via a blog post on
> > > hpc.guix.info.
> >
> > A manual is clearly more visible than a blog post. Also, even if
> > that blog post had everything, we've added blog posts to the
> > cookbook already, so it wouldn't even be that hard in this case.
>
> We agree, I guess. Maybe it was poorly worded but I was saying that
> the current situation is not satisfying and these patches are a tiny
> first step in improving the situation. Yes the manual is the
> location for the documentation and that’s some coming patches. :-)
>
> From my understanding, we are saying the same thing. :-)
From my understanding we are not. Or at least not under the assumption
that you're saying that adding example extensions will somehow improve
the situation. Again, we already have actual extensions packaged, I
don't see what the point would be in having an example one.
Toggle quote (29 lines)
> > > > > --8<---------------cut here---------------start-------------
> > > > > >8---
> > > > > $ guix shell guix-modules -- guix module -h
> > > > > guix: module: command not found
> > > > > Try `guix --help' for more information.
> > > > >
> > > > > $ guix shell guix-modules
> > > > > [env]$ guix module -h
> > > > > guix: module: command not found
> > > > > Try `guix --help' for more information.
> > > > > --8<---------------cut here---------------end---------------
> > > > > >8---
> > >
> > > > In case you really didn't know how to use extensions with guix
> > > > shell, it's guix shell guix your-extension -- guix blah,
> > > > assuming
> > > > your extension works with a slightly older guix.
> > >
> > > As shown by my snippet above, it does not work; at least on
> > > foreign distro.
> >
> > Look at your snippet, then back to mine, now back to your snippet,
> > now back to mine. Sadly, your snippet isn't mine, but it could be
> > mine if you added "guix" to the the packages listed before the --.
>
> Maybe I am wrong or maybe I miss a point but rely on the package
> ’guix’ is not an option for an extension. We had some discussions
> [1] about that on gwl-devel some time ago – which leads to
> GUIX_EXTENSION_PATH. :-)
IIUC this discussion is only tangentially related to what we're
discussing now. At the time of writing, only the guix package provides
GUIX_EXTENSION_PATH as a search path -- similar to how glib is one of
the few packages to provide XDG_DATA_DIRS.
Toggle quote (68 lines)
> Consider,
>
> guix shell guix <whatever> -- guix <something>
>
> then two revisions of Guix are involved:
>
> 1. one by ~/.config/current/bin/guix calling the subcommand ’shell’
> 2. one by ’-- guix <something>’ provided here by the package ’guix’
>
> When an user runs an extension, they expect to run their current
> Guix. For instance, consider that ’name-version’ is an extension
> displaying name and version.
>
> --8<---------------cut here---------------start------------->8---
> (define-module (guix extensions name-version)
> #:use-module (guix scripts)
> #:use-module (guix ui)
> #:use-module (guix packages)
> #:use-module (gnu packages)
> #:export (guix-name-version))
>
> (define-command (guix-name-version . args)
> (category extension)
> (synopsis "show name and version")
>
> (let* ((pkg (car args))
> (package (specification->package pkg))
> (name (package-name package))
> (version (package-version package)))
> (format #t (G_ "name: ~a~%version: ~a~%") name version)))
> --8<---------------cut here---------------end--------------->8---
>
> Using Guix 65cabb0, the use of this extension reads,
>
> --8<---------------cut here---------------start------------->8---
> $ GUIX_EXTENSIONS_PATH=/tmp/name-version/guix/extensions guix name-
> version parallel
> name: parallel
> version: 20220722
>
> $ guix shell guix
> [env]$ GUIX_EXTENSIONS_PATH=/tmp/name-version/guix/extensions guix
> name-version parallel
> name: parallel
> version: 20220522
> --8<---------------cut here---------------end--------------->8---
>
> There is no difference with an extension and a proper module once
> configured GUIX_EXTENSIONS_PATH adequately. So, equivalently:
>
> --8<---------------cut here---------------start------------->8---
> $ guix show parallel | recsel -p name,version
> name: parallel
> version: 20220722
>
> $ guix shell guix -- guix show parallel | recsel -p name,version
> name: parallel
> version: 20220522
> --8<---------------cut here---------------end--------------->8---
>
> That’s why the package guix is not provided (before --) by the
> snippets above. It is not a mistake and I still maintain there is an
> unexpected behaviour (bug?) for the extensions and ’guix shell’ – the
> fix you are proposing does not match the idea behind the extensions,
> IMHO.
>
> BTW, shell+extension is a corner case from my point of view. I also
> maintain it is unrelated to this patch submission. :-)
To be fair, the actual bug here is -- as I've said in a number of
patches already -- that manifests don't have first-class search paths.
Were it not for that, you could do guix shell normally.
However, this difference in package versions, while visible, should not
be something a *simple* extension needs to care about. Plus, I think
people have mentioned the "extensions as channels" pattern, which I
believe is what Andrew was using for Guix Home before it became
upstreamed (and might still be using).
Toggle quote (17 lines)
> From the feedback I got at the lightening talk in 10 years event, I
> assume the feature is barely known. I still miss what is the
> concrete objection with these patches. Could you elaborate? Do they
> break something? Are they not compliant?
>
> I got it, you find them useless. :-) But as I said, maybe I or
> someone else will improve next – is perfection not the enemy of the
> good?
>
> The two only Guix extensions I am aware of are ’gwl’ and ’guix-
> modules’. Both are complex and difficult starters, IMHO. Hence
> these tiny starter examples, for what they are worth.
>
> I am fine to expand ’guix-example’, write a section to the manual,
> etc. That’s the general idea with the submission of this patch. :-)
> Well, I am just missing the objections because these patches appears
> to me complementary and a first tiny step.
I reject the idea of including examples that are strictly less
explanatory than GNU hello -- which imho all the hitherto proposed ones
are -- as packages to install solely on the ground that gwl and guix-
modules are "complex and difficult starters". Of course, they are
complex by the nature of the real-world problems they are trying to
solve, but that doesn't mean there are no real-world problems with
simpler solutions.
The work a novice user would have to do to understand all of guix-
example would be to `guix build -S guix-example', then understand its
code, followed by `guix edit guix-example', understand that, and
finally apply it to their use case. Note how this includes commands
that are typically more on the contributor side. Also note how the
code is splintered in two segments so they have to switch between the
two (or it's tangled as in the case of guix-hello, which also has its
issues). The cookbook on the other hand can be read with the info
reader (or browser) of their choice, and is thus imho preferable. It
also offers a better way of putting the code together without literally
writing the extension code inside the package itself.
Cheers
