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

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

package to be installed is guix from the default channel.

---

guix/scripts/package.scm | 10 +++++++++-

1 file changed, 9 insertions(+), 1 deletion(-)

package to be installed is guix from the default channel.

---

guix/scripts/package.scm | 11 ++++++++++-

1 file changed, 10 insertions(+), 1 deletion(-)

Hullo.

"( via Guix-patches" via ???

♥

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.

I would write (report-error "…~%") sans (newline). If you

intentionally didn't, let's explicitly discuss that.

Kind regards,

T G-R

Heya,

On Mon Oct 17, 2022 at 5:24 PM BST, Tobias Geerinckx-Rice wrote:

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

-- (

package to be installed is guix from the default channel.

---

guix/scripts/package.scm | 10 +++++++++-

1 file changed, 9 insertions(+), 1 deletion(-)

Hi,

Cool! Nice initiative.

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

Instead of an error, I would prefer a warning. Because, sometimes it is

useful to have this Guix library. :-)

Cheers,

simon

Hi,

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

The Guix API would be available without having to 'guix install guix' in

the first place, no?

--

Thanks,

Maxim

Hello,

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

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

Hi Maxim,

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

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

On Fri Oct 28, 2022 at 8:44 AM BST, zimoun wrote:

What about just this?

guix shell guix

That's still possible.

-- (

Hi Simon,

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

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

Heyo,

zimoun ???

Sure.

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’?

Why not?

Or we are!

Kind regards,

T G-R

Tobias Geerinckx-Rice via Guix-patches via ???

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

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:

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:

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:

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:

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

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 ???

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.

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…

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’.

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

Hi Tobias,

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

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.

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’.

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.

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

Hi Simon,

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

[...]

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

tags 58583 + moreinfo

quit

Hi Maxim,

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

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