GNU bug report logs - #55139
package-location is wrong for transformed packages

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55139 in the body.
You can then email your comments to 55139 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: bug-guix <bug-guix <at> gnu.org>
Subject: package-location is wrong for transformed packages
Date: Tue, 26 Apr 2022 21:48:49 -0400

Hi Guix!

--8<---------------cut here---------------start------------->8---
> ,import (gnu packages) (guix packages)
> (car (find-packages-by-name "python2-pyalsaaudio"))
$1 = #<package python2-pyalsaaudio <at> 0.8.4 gnu/packages/audio.scm:4327 7f2b76fab160>
> (package-definition-location-code package $1)
$2 = #f
> (package-definition-location $2)
$3 = #<<location> file: "gnu/packages/audio.scm" line: 4327 column: 2>
--8<---------------cut here---------------end--------------->8---

This is wrong though, and gives the location of the parent package (the
one it inherited from).  This seems to be made on purpose (?) given the
code in (gnu build-system python):

--8<---------------cut here---------------start------------->8---
(package/inherit p
        (location (package-location p))

        ^ Here, we explicitly set the location to that of its parent.
        
        (name (let ((name (package-name p)))
                (string-append new-prefix
                               (if (string-prefix? old-prefix name)
                                   (substring name
                                              (string-length old-prefix))
                                   name))))
        (arguments
         (let ((python (if (promise? python)
                           (force python)
                           python)))
           (ensure-keyword-arguments (package-arguments p)
                                     `(#:python ,python)))))
--8<---------------cut here---------------end--------------->8---

Another related issue for package-with-python2 packages:

--8<---------------cut here---------------start------------->8---
> (package-definition-location-code $1)
$4 = #f
--8<---------------cut here---------------end--------------->8---

I was expecting to use this to get rid of all leaf Python 2 packages,
but it seems that may not work (as easily as I'd hoped).

Thanks,

Maxim

Message #8 received at 55139 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>, 55139 <at> debbugs.gnu.org
Subject: Re: package-location is wrong for transformed packages
Date: Wed, 27 Apr 2022 14:23:20 +0200

Am Dienstag, dem 26.04.2022 um 21:48 -0400 schrieb Maxim Cournoyer:
> Hi Guix!
> 
> --8<---------------cut here---------------start------------->8---
> > ,import (gnu packages) (guix packages)
> > (car (find-packages-by-name "python2-pyalsaaudio"))
> $1 = #<package python2-pyalsaaudio <at> 0.8.4 gnu/packages/audio.scm:4327
> 7f2b76fab160>
> > (package-definition-location-code package $1)
> $2 = #f
> > (package-definition-location $2)
> $3 = #<<location> file: "gnu/packages/audio.scm" line: 4327 column:
> 2>
> --8<---------------cut here---------------end--------------->8---
> 
> This is wrong though, and gives the location of the parent package
> (the one it inherited from).  This seems to be made on purpose (?)
> given the code in (gnu build-system python):
I'm pretty sure that this is done so that `guix edit' points you to the
package you want to edit rather than its wrapper.  While thus
incorrect, it is most often what you want.  Also, the wrapper should be
in its vicinity (usually the next package).

> --8<---------------cut here---------------start------------->8---
> (package/inherit p
>         (location (package-location p))
> 
>         ^ Here, we explicitly set the location to that of its parent.
>         
>         (name (let ((name (package-name p)))
>                 (string-append new-prefix
>                                (if (string-prefix? old-prefix name)
>                                    (substring name
>                                               (string-length old-
> prefix))
>                                    name))))
>         (arguments
>          (let ((python (if (promise? python)
>                            (force python)
>                            python)))
>            (ensure-keyword-arguments (package-arguments p)
>                                      `(#:python ,python)))))
> --8<---------------cut here---------------end--------------->8---
> 
> Another related issue for package-with-python2 packages:
> 
> --8<---------------cut here---------------start------------->8---
> > (package-definition-location-code $1)
> $4 = #f
> --8<---------------cut here---------------end--------------->8---
> 
> I was expecting to use this to get rid of all leaf Python 2 packages,
> but it seems that may not work (as easily as I'd hoped).
Note, that you can use guix graphs to detect leaves and then grep for
the variable name.  This still requires you to use Emacs for deleting
some three lines rather than doing so programmatically.

However, given that you have the location, you could try to filter out
the variable name, then detect whether it's in a package-with-python2
call within the same file.

Finally, you can try to just locally comment out that setter and it
might return the "true" path.  Note that I haven't tested this.  Since
you're probably using this for a more or less one-time script anyway, I
wouldn't be too bothered about it being a dirty hack.

Cheers :)

Message #11 received at 55139 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 55139 <at> debbugs.gnu.org
Subject: Re: bug#55139: package-location is wrong for transformed packages
Date: Mon, 02 May 2022 22:57:45 +0200

Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

>> ,import (gnu packages) (guix packages)
>> (car (find-packages-by-name "python2-pyalsaaudio"))
> $1 = #<package python2-pyalsaaudio <at> 0.8.4 gnu/packages/audio.scm:4327 7f2b76fab160>
>> (package-definition-location-code package $1)
> $2 = #f
>> (package-definition-location $2)
> $3 = #<<location> file: "gnu/packages/audio.scm" line: 4327 column: 2>
>
>
> This is wrong though, and gives the location of the parent package (the
> one it inherited from).  This seems to be made on purpose (?) given the
> code in (gnu build-system python):
>
> (package/inherit p
>         (location (package-location p))
>
>         ^ Here, we explicitly set the location to that of its parent.

Indeed, that’s on purpose; the rationale is that it’s more useful to see
the location of the original package (the Python 3 variant) than always
this one line in gnu/build-system/python.scm.

> Another related issue for package-with-python2 packages:
>
>> (package-definition-location-code $1)
> $4 = #f

Yes, I see it’s annoying, but that’s expected.

> I was expecting to use this to get rid of all leaf Python 2 packages,
> but it seems that may not work (as easily as I'd hoped).

You were willing to have a script that would automatically delete the
relevant lines, right?

It’s kinda silly but I think the script will have to estimate the
definition location by looking for “(define-public python2-…”.

HTH,
Ludo’.

Message #14 received at 55139 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 55139 <at> debbugs.gnu.org
Subject: Re: bug#55139: package-location is wrong for transformed packages
Date: Sun, 22 May 2022 01:16:32 -0400

Hi,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>>> ,import (gnu packages) (guix packages)
>>> (car (find-packages-by-name "python2-pyalsaaudio"))
>> $1 = #<package python2-pyalsaaudio <at> 0.8.4 gnu/packages/audio.scm:4327 7f2b76fab160>
>>> (package-definition-location-code package $1)
>> $2 = #f
>>> (package-definition-location $2)
>> $3 = #<<location> file: "gnu/packages/audio.scm" line: 4327 column: 2>
>>
>>
>> This is wrong though, and gives the location of the parent package (the
>> one it inherited from).  This seems to be made on purpose (?) given the
>> code in (gnu build-system python):
>>
>> (package/inherit p
>>         (location (package-location p))
>>
>>         ^ Here, we explicitly set the location to that of its parent.
>
> Indeed, that’s on purpose; the rationale is that it’s more useful to see
> the location of the original package (the Python 3 variant) than always
> this one line in gnu/build-system/python.scm.
>
>> Another related issue for package-with-python2 packages:
>>
>>> (package-definition-location-code $1)
>> $4 = #f
>
> Yes, I see it’s annoying, but that’s expected.
>
>> I was expecting to use this to get rid of all leaf Python 2 packages,
>> but it seems that may not work (as easily as I'd hoped).
>
> You were willing to have a script that would automatically delete the
> relevant lines, right?
>
> It’s kinda silly but I think the script will have to estimate the
> definition location by looking for “(define-public python2-…”.

Yeah, I ended up with this [0]:

--8<---------------cut here---------------start------------->8---
(define (locate-package-via-git name)
  "Return the location object corresponding to package NAME, searched via git."
  (let* ((input-pipe (open-pipe* OPEN_READ
				 "git" "grep" "-n" "--column"
                                 (format #f "^(define-public ~a$" name)))
	 (output (get-string-all input-pipe)) ;file:line:column:match
	 (exit-val (status:exit-val (close-pipe input-pipe))))
    (case exit-val
      ((0)
       (let ((components (string-split output #\:)))
         (location
          (first components)                   ;file
          (string->number (second components)) ;1-indexed line
          ;; FIXME: Comment discrepancy in (guix diagnostics), which
          ;; says the column is 0-indexed.
          (and=> (string->number (third components)) 1-)))) ;0-indexed column
      ((1) #f)                                            ;no match
      (else (error "git grep failed with status" exit-val)))))
--8<---------------cut here---------------end--------------->8---

and it does feel silly to have to shell out to git, but it did the job.

Thanks,

Maxim

[0]  https://notabug.org/apteryx/guix-api-examples/src/master/purge-python2-packages.scm#L42

Message #17 received at 55139 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 55139 <at> debbugs.gnu.org
Subject: Re: bug#55139: package-location is wrong for transformed packages
Date: Mon, 23 May 2022 15:28:10 +0200

Hi!

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> Yeah, I ended up with this [0]:
>
> (define (locate-package-via-git name)
>   "Return the location object corresponding to package NAME, searched via git."
>   (let* ((input-pipe (open-pipe* OPEN_READ
> 				 "git" "grep" "-n" "--column"
>                                  (format #f "^(define-public ~a$" name)))
> 	 (output (get-string-all input-pipe)) ;file:line:column:match
> 	 (exit-val (status:exit-val (close-pipe input-pipe))))
>     (case exit-val
>       ((0)
>        (let ((components (string-split output #\:)))
>          (location
>           (first components)                   ;file
>           (string->number (second components)) ;1-indexed line
>           ;; FIXME: Comment discrepancy in (guix diagnostics), which
>           ;; says the column is 0-indexed.
>           (and=> (string->number (third components)) 1-)))) ;0-indexed column
>       ((1) #f)                                            ;no match
>       (else (error "git grep failed with status" exit-val)))))
>
> and it does feel silly to have to shell out to git, but it did the job.
>
> Thanks,
>
> Maxim
>
> [0]  https://notabug.org/apteryx/guix-api-examples/src/master/purge-python2-packages.scm#L42

Nice, it’s good to have these examples—and hopefully we’ll soon be able
to remove a whole bunch of ‘python2-’ packages!

As for ‘package-definition-location’, I don’t think we can reasonably do
any better, so I’m tempted to close the bug.

WDYT?

Ludo’.

Message #22 received at 55139-done <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 55139-done <at> debbugs.gnu.org
Subject: Re: bug#55139: package-location is wrong for transformed packages
Date: Wed, 08 Jun 2022 17:29:08 -0400

Hi Ludovic,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi!
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> Yeah, I ended up with this [0]:
>>
>> (define (locate-package-via-git name)
>>   "Return the location object corresponding to package NAME, searched via git."
>>   (let* ((input-pipe (open-pipe* OPEN_READ
>> 				 "git" "grep" "-n" "--column"
>>                                  (format #f "^(define-public ~a$" name)))
>> 	 (output (get-string-all input-pipe)) ;file:line:column:match
>> 	 (exit-val (status:exit-val (close-pipe input-pipe))))
>>     (case exit-val
>>       ((0)
>>        (let ((components (string-split output #\:)))
>>          (location
>>           (first components)                   ;file
>>           (string->number (second components)) ;1-indexed line
>>           ;; FIXME: Comment discrepancy in (guix diagnostics), which
>>           ;; says the column is 0-indexed.
>>           (and=> (string->number (third components)) 1-)))) ;0-indexed column
>>       ((1) #f)                                            ;no match
>>       (else (error "git grep failed with status" exit-val)))))
>>
>> and it does feel silly to have to shell out to git, but it did the job.
>>
>> Thanks,
>>
>> Maxim
>>
>> [0]  https://notabug.org/apteryx/guix-api-examples/src/master/purge-python2-packages.scm#L42
>
> Nice, it’s good to have these examples—and hopefully we’ll soon be able
> to remove a whole bunch of ‘python2-’ packages!
>
> As for ‘package-definition-location’, I don’t think we can reasonably do
> any better, so I’m tempted to close the bug.

OK; thanks for your input.

At least it'll be recorded somewhere for the next person stumbling on
this behavior to discover.

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.