all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Tobias Geerinckx-Rice <me@tobias.gr>
Cc: "\(" <paren@disroot.org>,
	58583@debbugs.gnu.org,
	Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: [bug#58583] [PATCH 0/1] scripts: package: Forbid installation of the guix package.
Date: Wed, 02 Nov 2022 16:48:49 +0100	[thread overview]
Message-ID: <8735b1e4ri.fsf@gmail.com> (raw)
In-Reply-To: <87y1st4fli.fsf@nckx>

Hi Tobias,

On mer., 02 nov. 2022 at 14:19, Tobias Geerinckx-Rice via Guix-patches via <guix-patches@gnu.org> wrote:

> Thanks for the clarifications!  I hope you don't feel like you 
> were dragged into a discussion against your will.  If so, I really 
> do apologise.
>
> I think all intentions here were the opposite: to make sure that 
> even a ‘weak’ opinion was properly considered.  It might turn out 
> to be more robust than the ‘strong’ ones ;-)  That's one of Guix's 
> strengths IMO.

For sure. :-)


Well, we agree that many people are confused by

 1. which version of Guix they are running,
 2. the package named ’guix’ which time to time is installed with a
    wrong understanding about what it is.

And we agree that the patch is a way to address that.  We also agree
that raising a message when running “guix install guix” (whatever the
profile) is an appropriate mean to address the issue.

Where we disagree is only if the message must be an error stopping any
other actions or if the message must be a warning – letting people shoot
in their foot if they really want to, fully being aware that they could
be burnt.

Yours arguments are not convincing me that an error is adequate because
I am raising corner cases (e.g., guix as a Guile library).  And you are
not convinced by my arguments, pointing that are not worth the
exception.

Well, let agree that we disagree and move forward. :-)  I rally to the
proposal about put an error.  At worse, there is many workarounds for
people really wanting the package named ’guix’ in some profile. :-)


Just other minor comments – because now I am dragged into a discussion
against my will ;-) – so let keep my opinion as clear as I am able to.


> zimoun 写道:
>> Therefore, why do we provide the ’guix’ package in the first 
>> place?
>
> That ‘guix install guix’ is an error does *not* imply that the 
> mere existence of the ‘guix’ package is an error.  I think we can 
> keep those separate.

We agree that “guix install guix” is most of the time an error and an
user’s misunderstanding.  We want address the confusion and one part of
the confusion is from the package named ’guix’.  Therefore, it appears
to me a question: why do we provide the package named ’guix’ in the
first place?

This is a honest question.  Maybe this patch is not addressing at the
correct level the source of the confusion.  And maybe the fix should be
at another level.

Aside some corner cases as described elsewhere (guix as a Guile
library), why do we need to provide a package named ’guix’?  In order to
allow,

   guix shell -D guix

for feeding a development environment for Guix.  Something else?

Somehow, my point is not to imply that the package named ’guix’ is an
error but instead to think if we really need this package named ’guix’.


>> Well, maybe instead the package ’guix’, it should be renamed
>> ’guile-guix’ or ’guile-libguix’.
>
> That would be going against the spirit of our own naming rules, 
> unless you mean that it should be a ‘library-only’ variant that 
> lacks /bin/guix.

Euh, why is it going against the spirit of the naming rules?  All Guile
packages are prefixed by ’guile-’, as Haskell by ’ghc-’, as R by ’r-’,
etc.

And for instance, the package ’python-nose’ provides ’bin/nosetests’.
Idem for ’python-pylint’ and ’bin/pylint’; for the two I quickly found.


> Now *that* I do find mildly confusing—but only because it's 
> starting to get complex :-)  Do we then put /bin/guix in 
> ‘guix-libguix:bin’?  Or a second package?  Etc.

Here, I am confused. :-) Aside that ’guile-guix’ would be a perfectly
fine name, I miss the logic: on one hand a willing to error because
’bin/guix’ and on the other hand trying to define various outputs to
keep such ’bin/guix’.

Or I miss some humour behind.


Cheers,
simon




  reply	other threads:[~2022-11-02 15:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-17 12:16 [bug#58583] [PATCH 0/1] scripts: package: Forbid installation of the guix package ( via Guix-patches via
2022-10-17 12:18 ` [bug#58583] [PATCH 1/1] " ( via Guix-patches via
2022-10-17 12:22 ` [bug#58583] [PATCH v2] " ( via Guix-patches via
2022-10-17 16:24   ` Tobias Geerinckx-Rice via Guix-patches via
2022-10-17 16:43     ` ( via Guix-patches via
2022-10-17 16:50 ` [bug#58583] [PATCH v3] " ( via Guix-patches via
2022-10-17 18:14   ` zimoun
2022-10-27 20:04     ` [bug#58583] [PATCH 0/1] " Maxim Cournoyer
2022-10-28  7:44       ` zimoun
2022-10-28 14:31         ` ( via Guix-patches via
2022-10-28 15:47         ` Maxim Cournoyer
2022-10-28 16:20         ` Tobias Geerinckx-Rice via Guix-patches via
2022-10-28 17:01           ` Tobias Geerinckx-Rice via Guix-patches via
2022-11-02 11:47         ` zimoun
2022-11-02 13:19           ` Tobias Geerinckx-Rice via Guix-patches via
2022-11-02 15:48             ` zimoun [this message]
2022-11-03 15:03               ` Maxim Cournoyer
2022-11-03 18:32                 ` zimoun
2022-10-27 20:11   ` Maxim Cournoyer

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

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

  git send-email \
    --in-reply-to=8735b1e4ri.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=58583@debbugs.gnu.org \
    --cc=maxim.cournoyer@gmail.com \
    --cc=me@tobias.gr \
    --cc=paren@disroot.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.