unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: 58339@debbugs.gnu.org
Subject: [bug#58339] ’guix shell’ not working with GUIX_EXTENSIONS_PATH
Date: Sat, 08 Oct 2022 10:35:26 +0200	[thread overview]
Message-ID: <86v8ouu301.fsf@gmail.com> (raw)
In-Reply-To: <00943eca15a92b5985361d14b12b6ffe9794c187.camel@gmail.com>

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?


>> 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. :-)


>> > > --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. :-)

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. :-)



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.


Cheers,
simon


1: <https://yhetil.org/guix/875zh3w3yp.fsf@elephly.net/>




  reply	other threads:[~2022-10-08  8:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-06 16:36 [bug#58339] [PATCH 0/2] Add simple Guix extensions as example zimoun
2022-10-06 16:39 ` [bug#58339] [PATCH 1/2] gnu: Add guix-hello zimoun
2022-10-06 16:39   ` [bug#58339] [PATCH 2/2] gnu: Add guix-example zimoun
2022-10-06 19:58     ` Liliana Marie Prikler
2022-10-07  8:21       ` [bug#58339] ’guix shell’ not working with GUIX_EXTENSIONS_PATH zimoun
2022-10-07 18:21         ` Liliana Marie Prikler
2022-10-07 18:49           ` zimoun
2022-10-07 19:28             ` Liliana Marie Prikler
2022-10-08  8:35               ` zimoun [this message]
2022-10-08  9:43                 ` Liliana Marie Prikler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86v8ouu301.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=58339@debbugs.gnu.org \
    --cc=liliana.prikler@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).