[PATCH] guix package: Warn if uses has 'guix' package in profile.

  • Open
  • quality assurance status badge
Details
4 participants
  • Jakub K?dzio?ka
  • Tobias Geerinckx-Rice
  • Ricardo Wurmus
  • zimoun
Owner
unassigned
Submitted by
Jakub K?dzio?ka
Severity
normal
J
J
Jakub K?dzio?ka wrote on 3 Jan 2021 19:32
(address . guix-patches@gnu.org)
20210103183202.11224-1-kuba@kadziolka.net
* guix/scripts/package.scm (warn-about-guix-in-profile): New procedure.
(process-actions): Call WARN-ABOUT-GUIX-IN-PROFILE before executing
transaction.
---

Unresolved questions:
- Is this the right place to put warn-about-guix-in-profile?
- The warning message seems to be hard-wrapped. Is this the right
line length?
- Do we want to make this configurable? Some other warnings are, but in
those cases it is the threshold that gets configured. In this case,
there is no threshold.

guix/scripts/package.scm | 11 +++++++++++
1 file changed, 11 insertions(+)

Toggle diff (38 lines)
diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
index 6faf2adb7a..bc42bd7d84 100644
--- a/guix/scripts/package.scm
+++ b/guix/scripts/package.scm
@@ -9,6 +9,7 @@
;;; Copyright © 2019 Tobias Geerinckx-Rice <me@tobias.gr>
;;; Copyright © 2020 Ricardo Wurmus <rekado@elephly.net>
;;; Copyright © 2020 Simon Tournier <zimon.toutoune@gmail.com>
+;;; Copyright © 2021 Jakub K?dzio?ka <kuba@kadziolka.net>
;;;
;;; This file is part of GNU Guix.
;;;
@@ -863,6 +864,15 @@ processed, #f otherwise."
(switch-generation . ,switch-generation-action)
(delete-generations . ,delete-generations-action)))
+(define (warn-about-guix-in-profile manifest)
+ "Emit a warning if MANIFEST contains a 'guix' package."
+ (when (manifest-installed? manifest
+ (manifest-pattern
+ (name "guix")))
+ (warning (G_ "Installing the 'guix' package in a user profile is not recommended,
+as it will conflict with the installation managed by 'guix pull'. Consider running
+'guix package -r guix'.\n"))))
+
(define (process-actions store opts)
"Process any install/remove/upgrade action from OPTS."
@@ -928,6 +938,7 @@ processed, #f otherwise."
(manifest-entries manifest)))))
(warn-about-old-distro)
+ (warn-about-guix-in-profile new)
(unless (manifest-transaction-null? trans)
;; When '--manifest' is used, display information about TRANS as if we
--
2.29.2
Z
Z
zimoun wrote on 7 Jan 2021 17:39
(name . Jakub K?dzio?ka)(address . kuba@kadziolka.net)(address . 45632@debbugs.gnu.org)
CAJ3okZ2zw1PFLF6MW9BtTV6C0Qfr2v=JfHVSsCSOPy8L--cg9Q@mail.gmail.com
Hi,

On Sun, 3 Jan 2021 at 19:33, Jakub K?dzio?ka <kuba@kadziolka.net> wrote:
Toggle quote (14 lines)
>
> * guix/scripts/package.scm (warn-about-guix-in-profile): New procedure.
> (process-actions): Call WARN-ABOUT-GUIX-IN-PROFILE before executing
> transaction.
> ---
>
> Unresolved questions:
> - Is this the right place to put warn-about-guix-in-profile?
> - The warning message seems to be hard-wrapped. Is this the right
> line length?
> - Do we want to make this configurable? Some other warnings are, but in
> those cases it is the threshold that gets configured. In this case,
> there is no threshold.

What is the use case? I have missed some context.

For example, I have the package 'guix' in some of my profiles and I
would be annoyed to be warned. And I have it for good reasons. :-)
Once the story about extension is good enough, maybe the warning would
be a good advice, otherwise it could be confusing. IMHO.


All the best,
simon
T
T
Tobias Geerinckx-Rice wrote on 7 Jan 2021 18:15
(name . Jakub K?dzio?ka)(address . kuba@kadziolka.net)
87eeiwllbn.fsf@nckx
Jakub, Simon,

How about warning on pull instead? That should address the ‘halp,
me Guix be Benjamin Buttonin'’ support calls that I assume
inspired this.

Simon, would that reduce the noise in your case?

Jakub K?dzio?ka ???
Toggle quote (4 lines)
> - The warning message seems to be hard-wrapped. Is this the
> right
> line length?

Avoid hard-wrapping output entirely, by ’escaping’ the newlines

(warning (G_ "like\
this."))

Kind regards,

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

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCX/dBzA0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15tPkBAIKhTwWc5FUyIDzzoMq03J+axNnBcEiiVp4w43hP
jA0GAQCBU753ejSSWtUtzFijVSlYxyyNYadfEKQErWO/X13tDQ==
=T4v9
-----END PGP SIGNATURE-----

J
J
Jakub K?dzio?ka wrote on 7 Jan 2021 18:11
(name . zimoun)(address . zimon.toutoune@gmail.com)(address . 45632@debbugs.gnu.org)
C8D3D4MZKVJZ.3E7YJPFN19CND@gravity
On Thu Jan 7, 2021 at 5:39 PM CET, zimoun wrote:
Toggle quote (20 lines)
> Hi,
>
> On Sun, 3 Jan 2021 at 19:33, Jakub K?dzio?ka <kuba@kadziolka.net>
> wrote:
> >
> > * guix/scripts/package.scm (warn-about-guix-in-profile): New procedure.
> > (process-actions): Call WARN-ABOUT-GUIX-IN-PROFILE before executing
> > transaction.
> > ---
> >
> > Unresolved questions:
> > - Is this the right place to put warn-about-guix-in-profile?
> > - The warning message seems to be hard-wrapped. Is this the right
> > line length?
> > - Do we want to make this configurable? Some other warnings are, but in
> > those cases it is the threshold that gets configured. In this case,
> > there is no threshold.
>
> What is the use case? I have missed some context.

As the actual warning text explains, including the guix package in a
profile loaded by default breaks the 'guix pull' update mechanism, as
the guix package from the profile will take priority.

This is inspired by some tech support on IRC where this turned out to be
a root cause of a problem.

Moreover, if I'm not missing anything, running 'guix package -u' with
such a setup would *downgrade* the guix package each time.

Toggle quote (3 lines)
> For example, I have the package 'guix' in some of my profiles and I
> would be annoyed to be warned. And I have it for good reasons. :-)

Okay, I can see now that it is not wise to skimp on configurability for
this. Though, I would like to hear more about your usecase - how do you
keep your guix updated, for example?

Toggle quote (2 lines)
> Once the story about extension is good enough,

As in adding your own commands under the 'guix $CMD' namespace, or
something more sophisticated? For the former, git seems to have a quite
good mechanism - we could borrow that.

Regards,
Jakub K?dzio?ka
Z
Z
zimoun wrote on 7 Jan 2021 18:46
(name . Jakub K?dzio?ka)(address . kuba@kadziolka.net)(address . 45632@debbugs.gnu.org)
CAJ3okZ1WsK+YtJd5sNBkJKG2ozBCRjuSDy-WveJxf7ZoVmDasg@mail.gmail.com
Hi,

On Thu, 7 Jan 2021 at 18:27, Jakub K?dzio?ka <kuba@kadziolka.net> wrote:

Toggle quote (4 lines)
> As the actual warning text explains, including the guix package in a
> profile loaded by default breaks the 'guix pull' update mechanism, as
> the guix package from the profile will take priority.

Hum? I simply have ~/.config/guix/current/bin first in my PATH. Well,
I have the package 'guix' in my profile since long time because of
'emacs-guix' and never hit an issue.

Toggle quote (3 lines)
> This is inspired by some tech support on IRC where this turned out to be
> a root cause of a problem.

Could you indicate the day?

Toggle quote (3 lines)
> Moreover, if I'm not missing anything, running 'guix package -u' with
> such a setup would *downgrade* the guix package each time.

I do not know, I never upgrade this way. Because I only use
manifest.scm files. Even, from my personal taste '-u' and 'guix
upgrade' are Guix abomination and should not exist; another story. ;-)

Again if ~/.config/guix/current/bin first in the PATH, then it should
not be an issue, I guess.

Toggle quote (7 lines)
> > For example, I have the package 'guix' in some of my profiles and I
> > would be annoyed to be warned. And I have it for good reasons. :-)
>
> Okay, I can see now that it is not wise to skimp on configurability for
> this. Though, I would like to hear more about your usecase - how do you
> keep your guix updated, for example?

Basically, "guix pull" and "guix package -m". But I am tracking this
file "guix describe -f channels > channels.scm" and I also do "guix
time-machine -C channels.scm -- package -m manifest.scm".
Otherwise, when I want to give a try for a package, simply "guix
environment --ad-hoc"; time to time with "time-machine" too.

Toggle quote (6 lines)
> > Once the story about extension is good enough,
>
> As in adding your own commands under the 'guix $CMD' namespace, or
> something more sophisticated? For the former, git seems to have a quite
> good mechanism - we could borrow that.

From my understanding, Git use shell tricks and cannot be borrowed.
The idea is to have "guix <foo>"; for details, see the recent patch
about extensions by Ricardo and discussion on #guix-hpc (because GWL
is an extension).

All the best,
simon
Z
Z
zimoun wrote on 7 Jan 2021 18:56
CAJ3okZ0bQ4ruVpqv96Ah_rhTBbYOOEt9WyEtfdAW+dMcNvvhCg@mail.gmail.com
Hi Tobias,

On Thu, 7 Jan 2021 at 18:23, Tobias Geerinckx-Rice via Guix-patches
via <guix-patches@gnu.org> wrote:

Toggle quote (4 lines)
> How about warning on pull instead? That should address the ‘halp,
> me Guix be Benjamin Buttonin'’ support calls that I assume
> inspired this.

Wait, does someone install packages in the profile
"~/.config/guix/current"? And does they install the package 'guix' in
this profile? Nan...


Toggle quote (2 lines)
> Simon, would that reduce the noise in your case?

I am not sure to understand what the problem is; I should miss
something. My config is simply '~/.config/guix/current/bin' first in
my PATH and I am doing it manually with ~/.bash_profile. And I have a
lot of profiles that are sourced with a for-loop, some of them contain
the package 'guix'. And I have never hit an issue but I do not use
'upgrade'. Howver, I am mainly using Guix on Debian. Is the issue
Guix System specific?

Well, if the conflict is between the package 'guix' and the 'upgrade'
command, then the warning should be there, IMHO.


All the best,
simon
J
J
Jakub K?dzio?ka wrote on 7 Jan 2021 18:58
(address . 45632@debbugs.gnu.org)
C8D4CZ61UT11.1NVSH9KIFRCCP@gravity
On Thu Jan 7, 2021 at 6:56 PM CET, zimoun wrote:
Toggle quote (3 lines)
> Well, if the conflict is between the package 'guix' and the 'upgrade'
> command, then the warning should be there, IMHO.

The upgrade command is not part of the problem here, the same can be
observed if you use 'guix package -m' instead.

You avoid the problem by putting ~/.config/guix/current/bin first in
your path. I just checked, and that is the default on Guix System.
However, on a foreign distro, ~/.guix-profile/bin will be first in $PATH
unless the user intervenes with manual configuration.

In light of this, perhaps a better solution would be to unify the
profile loading in foreign-Guix's /etc/profile/guix.sh with Guix
System's /etc/profile?

The problem with that is, /etc/profile/guix.sh is only created once by
guix-install.sh, and doesn't get updated... perhaps *this* is something
worth fixing, to start with?

Toggle quote (8 lines)
> > How about warning on pull instead? That should address the ‘halp,
> > me Guix be Benjamin Buttonin'’ support calls that I assume
> > inspired this.
>
> Wait, does someone install packages in the profile
> "~/.config/guix/current"? And does they install the package 'guix' in
> this profile? Nan...

Nah, the scenario is much less convoluted:

1. $PATH contains ~/.guix-profile/bin:~/.config/guix/current/bin, in
that order, as that is currently the default on a foreign distro.

2. User adds the guix package to their ~/.guix-profile. This doesn't
need to happen with 'guix package -i', in fact the IRC conversation that
inspired this [1] (though I seem to recall earlier occurrences of the
same problem) the user was making use of a manifest file. It might even
be easier to encounter this with a manifest file due to its clean-slate
nature.

3. ~/.guix-profile/bin/guix now takes priority. This means
- guix describe doesn't work
- guix pull has no effect
- guix package (-u or -m) will use an older 'guix' package than is
currently installed, as a packaged guix version doesn't contain the
package definition of itself, but the one that was previously
packaged.

I hope this helps resolve your confusion.

Regards,
Jakub K?dzio?ka

Z
Z
zimoun wrote on 7 Jan 2021 20:25
(name . Jakub K?dzio?ka)(address . kuba@kadziolka.net)
CAJ3okZ0RKJDE_so5YNADbjVAP8OzneCxP_DjcysLssD_OM0Puw@mail.gmail.com
Hi,

On Thu, 7 Jan 2021 at 19:24, Jakub K?dzio?ka <kuba@kadziolka.net> wrote:

[...]

Toggle quote (4 lines)
> The problem with that is, /etc/profile/guix.sh is only created once by
> guix-install.sh, and doesn't get updated... perhaps *this* is something
> worth fixing, to start with?

[...]

Toggle quote (2 lines)
> I hope this helps resolve your confusion.

Thanks for the explanations. Yes, maybe guix-install.sh and
/etc/profile/guix.sh should be fixed before adding a warning. Because
somehow, the problem is not to have the package 'guix' but the order
in PATH.

All the best,
simon
R
R
Ricardo Wurmus wrote on 7 Jan 2021 21:31
(name . zimoun)(address . zimon.toutoune@gmail.com)
87y2h4fpza.fsf@elephly.net
zimoun <zimon.toutoune@gmail.com> writes:

Toggle quote (11 lines)
>> > Once the story about extension is good enough,
>>
>> As in adding your own commands under the 'guix $CMD' namespace, or
>> something more sophisticated? For the former, git seems to have a quite
>> good mechanism - we could borrow that.
>
> From my understanding, Git use shell tricks and cannot be borrowed.
> The idea is to have "guix <foo>"; for details, see the recent patch
> about extensions by Ricardo and discussion on #guix-hpc (because GWL
> is an extension).

This is a solved problem as far as I’m concerned. (It still needs to be
documented in the manual and maybe in the cookbook.)

You need to set GUIX_EXTENSIONS_PATH to a location that contains a Guile
module “(guix extensions my-command)” that defines “my-command” with
“define-command” (so it needs to import (guix scripts)). The category
should be “extension” (it’s a new category that has been added
recently).

As long as that’s the case Guix will be able to list it in “guix --help”
and execute it.

Here is the entry point of the Guix Workflow Language, which uses this
very mechanism:


--
Ricardo
?
Your comment

Commenting via the web interface is currently disabled.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 45632
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