[bug#58583] [PATCH 0/1] scripts: package: Forbid installation of the guix package.

[zimoun <zimon.toutoune@gmail.com>]

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