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

  • Open
  • quality assurance status badge
Details
5 participants
  • Christopher Baines
  • Maxim Cournoyer
  • Tobias Geerinckx-Rice
  • (
  • zimoun
Owner
unassigned
Submitted by
(
Severity
normal
(
(
( wrote on 17 Oct 2022 14:16
(address . guix-patches@gnu.org)
20221017121642.15468-1-paren@disroot.org
This patch forbids installation of the ``guix'' package through ``guix package''
et al. It's a wee bit of a hack, but after some discussion on IRC, we seemed to
come to the conclusion that this would be the best thing to do, and it will
finally fix the long-standing issue with newcomers running ``guix install guix''.

( (1):
scripts: package: Forbid installation of the guix package.

guix/scripts/package.scm | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

--
2.38.0
(
(
( wrote on 17 Oct 2022 14:18
[PATCH 1/1] scripts: package: Forbid installation of the guix package.
(address . 58583@debbugs.gnu.org)(name . ()(address . paren@disroot.org)
20221017121827.15571-1-paren@disroot.org
* guix/scripts/package.scm (package->manifest-entry*): Fail if the
package to be installed is guix from the default channel.
---
guix/scripts/package.scm | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

Toggle diff (23 lines)
diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
index 7ba2661bbb..886415f41e 100644
--- a/guix/scripts/package.scm
+++ b/guix/scripts/package.scm
@@ -699,7 +699,15 @@ (define (store-item->manifest-entry item)
(define (package->manifest-entry* package output)
"Like 'package->manifest-entry', but attach PACKAGE provenance meta-data to
-the resulting manifest entry."
+the resulting manifest entry, and report an error if PACKAGE is the 'guix'
+package from the default channel."
+ (when (and (string=? (package-name package) "guix")
+ (string-prefix? "gnu/" (location-file
+ (package-location package))))
+ (report-error (G_ "the 'guix' package should not be installed"))
+ (newline (current-error-port))
+ (display-hint (G_ "use 'guix pull' to fetch the latest Guix revision"))
+ (exit 1))
(manifest-entry-with-provenance
(package->manifest-entry package output)))
--
2.38.0
(
(
( wrote on 17 Oct 2022 14:22
[PATCH v2] scripts: package: Forbid installation of the guix package.
(address . 58583@debbugs.gnu.org)(name . ()(address . paren@disroot.org)
20221017122254.16230-1-paren@disroot.org
* guix/scripts/package.scm (package->manifest-entry*): Fail if the
package to be installed is guix from the default channel.
---
guix/scripts/package.scm | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)

Toggle diff (31 lines)
diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
index 7ba2661bbb..d0feb2063a 100644
--- a/guix/scripts/package.scm
+++ b/guix/scripts/package.scm
@@ -12,6 +12,7 @@
;;; Copyright © 2018 Steve Sprang <scs@stevesprang.com>
;;; Copyright © 2022 Josselin Poiret <dev@jpoiret.xyz>
;;; Copyright © 2022 Antero Mejr <antero@mailbox.org>
+;;; Copyright © 2022 ( <paren@disroot.org>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -699,7 +700,15 @@ (define (store-item->manifest-entry item)
(define (package->manifest-entry* package output)
"Like 'package->manifest-entry', but attach PACKAGE provenance meta-data to
-the resulting manifest entry."
+the resulting manifest entry, and report an error if PACKAGE is the 'guix'
+package from the default channel."
+ (when (and (string=? (package-name package) "guix")
+ (string-prefix? "gnu/" (location-file
+ (package-location package))))
+ (report-error (G_ "the 'guix' package should not be installed"))
+ (newline (current-error-port))
+ (display-hint (G_ "use 'guix pull' to fetch the latest Guix revision"))
+ (exit 1))
(manifest-entry-with-provenance
(package->manifest-entry package output)))
--
2.38.0
T
T
Tobias Geerinckx-Rice wrote on 17 Oct 2022 18:24
(name . ()(address . paren@disroot.org)
871qr6e7fb.fsf@nckx
Hullo.

"( via Guix-patches" via ???
Toggle quote (4 lines)
> * guix/scripts/package.scm (package->manifest-entry*): Fail if
> the
> package to be installed is guix from the default channel.

♥

As noted elsewhere, I've come to support this, er, straightforward
approach. It might offend some readers, so let's leave this open
for comment a bit longer.

I should like to merge it before 1.4, though.

Toggle quote (4 lines)
> + (report-error (G_ "the 'guix' package should not be
> installed"))
> + (newline (current-error-port))

I would write (report-error "…~%") sans (newline). If you
intentionally didn't, let's explicitly discuss that.

Kind regards,

T G-R
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCY02D6A0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15XgcBALNRWnzTtDX6uwX2X2teEbidhdXbIFSnNWwUqZ+e
g/1aAQCJ6LY211z5cJTHVEi9RjNpJxMM7HgwQ4Jx2JUJqxOEDA==
=yHcO
-----END PGP SIGNATURE-----

(
(
( wrote on 17 Oct 2022 18:43
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
CNOCKHY5OTZP.1MQ2W28DK5FZJ@guix-framework
Heya,

On Mon Oct 17, 2022 at 5:24 PM BST, Tobias Geerinckx-Rice wrote:
Toggle quote (7 lines)
> > + (report-error (G_ "the 'guix' package should not be
> > installed"))
> > + (newline (current-error-port))
>
> I would write (report-error "…~%") sans (newline). If you
> intentionally didn't, let's explicitly discuss that.

Agh, silly me. I'll correct that in a moment.

-- (
(
(
( wrote on 17 Oct 2022 18:50
[PATCH v3] scripts: package: Forbid installation of the guix package.
(address . 58583@debbugs.gnu.org)(name . ()(address . paren@disroot.org)
20221017165057.15648-1-paren@disroot.org
* guix/scripts/package.scm (package->manifest-entry*): Fail if the
package to be installed is guix from the default channel.
---
guix/scripts/package.scm | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

Toggle diff (30 lines)
diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
index 7ba2661bbb..9f023ea7b5 100644
--- a/guix/scripts/package.scm
+++ b/guix/scripts/package.scm
@@ -12,6 +12,7 @@
;;; Copyright © 2018 Steve Sprang <scs@stevesprang.com>
;;; Copyright © 2022 Josselin Poiret <dev@jpoiret.xyz>
;;; Copyright © 2022 Antero Mejr <antero@mailbox.org>
+;;; Copyright © 2022 ( <paren@disroot.org>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -699,7 +700,14 @@ (define (store-item->manifest-entry item)
(define (package->manifest-entry* package output)
"Like 'package->manifest-entry', but attach PACKAGE provenance meta-data to
-the resulting manifest entry."
+the resulting manifest entry, and report an error if PACKAGE is the 'guix'
+package from the default channel."
+ (when (and (string=? (package-name package) "guix")
+ (string-prefix? "gnu/" (location-file
+ (package-location package))))
+ (report-error (G_ "the 'guix' package should not be installed~%"))
+ (display-hint (G_ "use 'guix pull' to fetch the latest Guix revision"))
+ (exit 1))
(manifest-entry-with-provenance
(package->manifest-entry package output)))
--
2.38.0
Z
Z
zimoun wrote on 17 Oct 2022 20:14
(name . ()(address . paren@disroot.org)
874jw2l3m6.fsf@gmail.com
Hi,

Cool! Nice initiative.

On lun., 17 oct. 2022 at 17:50, "\( via Guix-patches" via <guix-patches@gnu.org> wrote:

Toggle quote (2 lines)
> + (report-error (G_ "the 'guix' package should not be installed~%"))

Instead of an error, I would prefer a warning. Because, sometimes it is
useful to have this Guix library. :-)


Cheers,
simon
M
M
Maxim Cournoyer wrote on 27 Oct 2022 22:04
Re: bug#58583: [PATCH 0/1] scripts: package: Forbid installation of the guix package.
(name . zimoun)(address . zimon.toutoune@gmail.com)
87ilk5hw3g.fsf_-_@gmail.com
Hi,

zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (11 lines)
> Hi,
>
> Cool! Nice initiative.
>
> On lun., 17 oct. 2022 at 17:50, "\( via Guix-patches" via <guix-patches@gnu.org> wrote:
>
>> + (report-error (G_ "the 'guix' package should not be installed~%"))
>
> Instead of an error, I would prefer a warning. Because, sometimes it is
> useful to have this Guix library. :-)

The Guix API would be available without having to 'guix install guix' in
the first place, no?

--
Thanks,
Maxim
M
M
Maxim Cournoyer wrote on 27 Oct 2022 22:11
(name . ()(address . paren@disroot.org)(address . 58583@debbugs.gnu.org)
87eduthvs0.fsf_-_@gmail.com
Hello,

"(" <paren@disroot.org> writes:

Toggle quote (34 lines)
> * guix/scripts/package.scm (package->manifest-entry*): Fail if the
> package to be installed is guix from the default channel.
> ---
> guix/scripts/package.scm | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
> index 7ba2661bbb..9f023ea7b5 100644
> --- a/guix/scripts/package.scm
> +++ b/guix/scripts/package.scm
> @@ -12,6 +12,7 @@
> ;;; Copyright © 2018 Steve Sprang <scs@stevesprang.com>
> ;;; Copyright © 2022 Josselin Poiret <dev@jpoiret.xyz>
> ;;; Copyright © 2022 Antero Mejr <antero@mailbox.org>
> +;;; Copyright © 2022 ( <paren@disroot.org>
> ;;;
> ;;; This file is part of GNU Guix.
> ;;;
> @@ -699,7 +700,14 @@ (define (store-item->manifest-entry item)
>
> (define (package->manifest-entry* package output)
> "Like 'package->manifest-entry', but attach PACKAGE provenance meta-data to
> -the resulting manifest entry."
> +the resulting manifest entry, and report an error if PACKAGE is the 'guix'
> +package from the default channel."
> + (when (and (string=? (package-name package) "guix")
> + (string-prefix? "gnu/" (location-file
> + (package-location package))))
> + (report-error (G_ "the 'guix' package should not be installed~%"))
> + (display-hint (G_ "use 'guix pull' to fetch the latest Guix revision"))
> + (exit 1))
> (manifest-entry-with-provenance
> (package->manifest-entry package output)))

Instead of exiting directly here, would it make sense to use
raise-exception with a compounded message and &fix-hint condition? When
working with the Guix API, I prefer to encounter exceptions rather than
errors + exit. For a recent example I used, see:

--
Thanks,
Maxim
Z
Z
zimoun wrote on 28 Oct 2022 09:44
Re: [bug#58583] [PATCH 0/1] scripts: package: Forbid installation of the guix package.
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
86a65g8k9a.fsf@gmail.com
Hi Maxim,

On Thu, 27 Oct 2022 at 16:04, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

Toggle quote (8 lines)
>>> + (report-error (G_ "the 'guix' package should not be installed~%"))
>>
>> Instead of an error, I would prefer a warning. Because, sometimes it is
>> useful to have this Guix library. :-)
>
> The Guix API would be available without having to 'guix install guix' in
> the first place, no?

Not necessary or I am missing something. For instance, you want to
build some Guile application relying on the Guix library; similarly as
you have, say, guile-commonmark or any other Guile packages.

Yes, it is possible to do without installing the package guix but it is
not handy. Aside, it is not always clear which revision of the API is
available when the package guix fixes it.

For instance, if an user packs their Guile application using some other
Guile libraries including the Guix library, then for developing, it
becomes not possible to just locally create a profile.

Well, I do not have a strong opinion on that, for what it is worth, I
would prefer a strong warning instead of an hard error. But maybe I am
missing something.


Cheers,
simon
(
(
( wrote on 28 Oct 2022 16:31
(address . 58583@debbugs.gnu.org)
CNXMNKC5047E.45IIR8D2HMB4@guix-framework
On Fri Oct 28, 2022 at 8:44 AM BST, zimoun wrote:
Toggle quote (4 lines)
> Not necessary or I am missing something. For instance, you want to
> build some Guile application relying on the Guix library; similarly as
> you have, say, guile-commonmark or any other Guile packages.

What about just this?

guix shell guix

That's still possible.

-- (
M
M
Maxim Cournoyer wrote on 28 Oct 2022 17:47
(name . zimoun)(address . zimon.toutoune@gmail.com)
87k04keyr0.fsf@gmail.com
Hi Simon,

zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (28 lines)
> Hi Maxim,
>
> On Thu, 27 Oct 2022 at 16:04, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>>>> + (report-error (G_ "the 'guix' package should not be installed~%"))
>>>
>>> Instead of an error, I would prefer a warning. Because, sometimes it is
>>> useful to have this Guix library. :-)
>>
>> The Guix API would be available without having to 'guix install guix' in
>> the first place, no?
>
> Not necessary or I am missing something. For instance, you want to
> build some Guile application relying on the Guix library; similarly as
> you have, say, guile-commonmark or any other Guile packages.
>
> Yes, it is possible to do without installing the package guix but it is
> not handy. Aside, it is not always clear which revision of the API is
> available when the package guix fixes it.
>
> For instance, if an user packs their Guile application using some other
> Guile libraries including the Guix library, then for developing, it
> becomes not possible to just locally create a profile.
>
> Well, I do not have a strong opinion on that, for what it is worth, I
> would prefer a strong warning instead of an hard error. But maybe I am
> missing something.

Does the benefit of fixing the Guix API used via a user profile
installed Guix package outweigh the cons of downgrading the version of
guix used as the user's package manager? I don't think so. By
installing the inner 'guix' into your user profile, you are basically
downgrading its version compared to the one you used to install it.
That's a pretty confusing thing to happen for most users.

As paren suggested, I think it's best to enter a dedicated 'guix shell'
profile with Guix when developing with the Guix API, else use the 'guix
repl' ability to run scripts.

It may be slightly inconvenient, but it's better than allowing Guix to
be silently downgraded upon unsuspecting users, in my opinion.

--
Thanks,
Maxim
T
T
Tobias Geerinckx-Rice wrote on 28 Oct 2022 18:20
(name . zimoun)(address . zimon.toutoune@gmail.com)
87r0yrzzht.fsf@nckx
Heyo,

zimoun ???
Toggle quote (6 lines)
> Not necessary or I am missing something. For instance, you want
> to
> build some Guile application relying on the Guix library;
> similarly as
> you have, say, guile-commonmark or any other Guile packages.

Sure.

Toggle quote (6 lines)
> Yes, it is possible to do without installing the package guix
> but it is
> not handy. Aside, it is not always clear which revision of the
> API is
> available when the package guix fixes it.

OK. But could you explain more clearly how

$ guix install guix

is involved, and how it is ‘handy’?

How does one continue to use guix *as a package manager*, having
now silently broken ‘guix pull’?

Toggle quote (6 lines)
> For instance, if an user packs their Guile application using
> some other
> Guile libraries including the Guix library, then for developing,
> it
> becomes not possible to just locally create a profile.

Why not?

Toggle quote (2 lines)
> But maybe I am missing something.

Or we are!

Kind regards,

T G-R
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCY1wCjw0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW150YIA/iNxJlHaHHAHrFvSEtPDlTv9ack2TDRgBVOkyFVh
zzmJAP0dSxgBYgXgwbwAwtaL/a1tL7W5kNFSKQ4dYUlXdgrmDQ==
=DNyT
-----END PGP SIGNATURE-----

T
T
Tobias Geerinckx-Rice wrote on 28 Oct 2022 19:01
87mt9fzxri.fsf@nckx
Tobias Geerinckx-Rice via Guix-patches via ???
Toggle quote (9 lines)
>> For instance, if an user packs their Guile application using
>> some
>> other
>> Guile libraries including the Guix library, then for
>> developing, it
>> becomes not possible to just locally create a profile.
>
> Why not?

Would this be address by refusing only to ‘guix install guix’
without an explicit --profile argument? This would eliminate 99%
of unintentional footguns. We could still warn.

Kind regards,

T G-R
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCY1wLUQ0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15KYkA/iFEORnCT2kxYf6z4ChHeQ/dFdCNMzWKguhfJOWY
AWlCAQCICqzphp0HTivVfh6p2ZnjxxyUoyzOwHTOn1dWp+WXDA==
=uvVU
-----END PGP SIGNATURE-----

Z
Z
zimoun wrote on 2 Nov 2022 12:47
874jvhh92c.fsf@gmail.com
Hi (, Maxim and Tobias,

Well, as I said, I do not have a strong opinion. If 3 of you think an
error is better than a warning, then I rally to the proposal.

Minor comments about yours. :-)


On ven., 28 oct. 2022 at 15:31, "\( via Guix-patches" via <guix-patches@gnu.org> wrote:

Toggle quote (6 lines)
> What about just this?
>
> guix shell guix
>
> That's still possible.

To be precise, the correct would be:

guix time-machine -C channels.scm -- shell guix

which is… equivalent to define a profile. ;-) i.e.,

guix package -i guix -p my/dev


On ven., 28 oct. 2022 at 11:47, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

Toggle quote (7 lines)
> Does the benefit of fixing the Guix API used via a user profile
> installed Guix package outweigh the cons of downgrading the version of
> guix used as the user's package manager? I don't think so. By
> installing the inner 'guix' into your user profile, you are basically
> downgrading its version compared to the one you used to install it.
> That's a pretty confusing thing to happen for most users.

I agree. However, to me, it is a warning (or a hint) – «hey you are
probably doing something wrong» – and not an error – «we provide you
something but no, not this way».

Therefore, why do we provide the ’guix’ package in the first place?


(BTW, I think the correct way to use Guix as a library is to use it via
GUIX_EXTENSIONS_PATH as pioneered by gwl and followed by
guix-modules. :-))


On ven., 28 oct. 2022 at 18:20, Tobias Geerinckx-Rice via Guix-patches via <guix-patches@gnu.org> wrote:

Toggle quote (3 lines)
> How does one continue to use guix *as a package manager*, having
> now silently broken ‘guix pull’?

There is a confusion here, maybe? Guix is also a Guile library and that
library is designed around package management.

Well, maybe instead the package ’guix’, it should be renamed
’guile-guix’ or ’guile-libguix’.



On ven., 28 oct. 2022 at 19:01, Tobias Geerinckx-Rice via Guix-patches via <guix-patches@gnu.org> wrote:

Toggle quote (4 lines)
> Would this be address by refusing only to ‘guix install guix’
> without an explicit --profile argument? This would eliminate 99%
> of unintentional footguns. We could still warn.

Personally, I do not consider ~/.guix-profile more special. But maybe,
it would help to address the newcomer’s confusion.



Again, I think a strong warning is better than a hard error but I do not
have a strong opinion.


Cheers,
simon
T
T
Tobias Geerinckx-Rice wrote on 2 Nov 2022 14:19
(name . zimoun)(address . zimon.toutoune@gmail.com)
87y1st4fli.fsf@nckx
Heyo,

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.

I'll not ask further questions below.

zimoun ???
Toggle quote (3 lines)
> 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.

Toggle quote (8 lines)
>> How does one continue to use guix *as a package manager*,
>> having
>> now silently broken ‘guix pull’?
>
> There is a confusion here, maybe? Guix is also a Guile library
> and that
> library is designed around package management.

Right. My problem is: I don't understand what's confusing about
that fact, so it's hard to communicate effectively about what I
don't see…

Toggle quote (3 lines)
> 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.

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.

So I'd rather keep ‘guix’ available as ‘guix’.

Toggle quote (2 lines)
> Personally, I do not consider ~/.guix-profile more special.

Nor do I. I agree that ‘-p ~/.guix-profile’ shouldn't be magical,
or I would have suggested an approach different from ('s from the
start.

Kind regards,

T G-R
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCY2J5CQ0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15TYkBAKUN83jRrDtxln03pJDGqpKrcd8mil+P0hfinwd7
mybUAQD2+aC9cd8MsnaJmZcYi6nqja5vzLG7jJstexSNPzAfCw==
=hTUH
-----END PGP SIGNATURE-----

Z
Z
zimoun wrote on 2 Nov 2022 16:48
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
8735b1e4ri.fsf@gmail.com
Hi Tobias,

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

Toggle quote (9 lines)
> 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.


Toggle quote (8 lines)
> 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’.


Toggle quote (7 lines)
>> 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.


Toggle quote (4 lines)
> 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
M
M
Maxim Cournoyer wrote on 3 Nov 2022 16:03
(name . zimoun)(address . zimon.toutoune@gmail.com)
87sfj0axlv.fsf@gmail.com
Hi Simon,

zimoun <zimon.toutoune@gmail.com> writes:

[...]

Toggle quote (7 lines)
> 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.

Referring to info '(guix) Package Naming', that doesn't seem to be a
written rule; my rule of thumb here would be: if something exists to be
used exclusively as a command, drop the language-specific prefix. If it
is a library or both a library and a command, keep the prefix. In
doubt, keep the prefix.

So supposing 'git' was implemented in Python, it'd still be called
'git', not 'python-git'. pylint could/should probably be named
"pylint", but perhaps it's also usable as a Python library, I haven't
checked.

--
Thanks,
Maxim
C
C
Christopher Baines wrote on 3 Nov 2022 17:11
tag 58583 moreinfo
(address . control@debbugs.gnu.org)
8735b0yq42.fsf@cbaines.net
tags 58583 + moreinfo
quit
Z
Z
zimoun wrote on 3 Nov 2022 19:32
Re: [bug#58583] [PATCH 0/1] scripts: package: Forbid installation of the guix package.
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
87v8nvanxy.fsf@gmail.com
Hi Maxim,

On jeu., 03 nov. 2022 at 11:03, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

Toggle quote (6 lines)
> Referring to info '(guix) Package Naming', that doesn't seem to be a
> written rule; my rule of thumb here would be: if something exists to be
> used exclusively as a command, drop the language-specific prefix. If it
> is a library or both a library and a command, keep the prefix. In
> doubt, keep the prefix.

Yes, for sure. And I agree that we should follow as close as possible
this rule of thumb because it provides a good consistency.

My point is: the line is not always clear and for some packages we have
a grey area.

Another example, we have pandoc and ghc-pandoc. IIRC, these two
packages had been created for a similar reason as we are discussing
here; from my understanding.

All in all, I am convinced that raising an error when installing the
package named ’guix’ is not an appropriated patch for fixing the
confusion generated by the package named ’guix’.

Well, I have said my opinion and this patch is not a breaking change
revolutionizing the world neither. ;-) Feel free to push a patch
containing what you find appropriate.


Cheers,
simon
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 58583@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 58583
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch