Resolving package inheritance issue

Done

Details

4 participants

Josselin Poiret
Maxim Cournoyer
Sharlatan Hellseher
Simon Tournier

Owner: unassigned

Submitted by: Sharlatan Hellseher

Severity: normal

Sharlatan Hellseher wrote on 31 Jan 02:01 +0100

Recipients:(address . bug-guix@gnu.org)

Message-ID:87sf2es4cc.fsf@gmail.com

Hi Guix!

Toggle quote (1 lines)

> ./etc/teams.scm cc core

- guix@cbaines.net

- dev@jpoiret.xyz

- ludo@gnu.org

- othacehe@gnu.org

- rekado@elephly.net

- zimon.toutoune@gmail.com

- me@tobias.gr

Long story short, how to resolve package inheritance which would not

break CI ;-) ?

While reviewing and amending patch series from

https://issues.guix.gnu.org/61946 I've stabilized it on my local

checkout, which passed complete reconfigure and rebuild few times

(not...).

When I've pushed changes to https://git.savannah.gnu.org/cgit/guix.git

the commit f8c2d8141efef4565d12d8247bade069889b720e broke CI

https://ci.guix.gnu.org/eval/1086875/log/raw.

Toggle snippet (15 lines)

In unknown file:

6 (primitive-load-path "gnu/packages/web" #<procedure 7f79c08dc920 at ice-9/boot-9.scm:3551:37 ()>)

In ice-9/eval.scm:

619:8 5 (_ #f)

626:19 4 (_ #<directory (gnu packages web) 7f79c17a2820>)

173:55 3 (_ #(#(#(#<directory (gnu packages web) 7f79c17a2820> "minify") #<procedure arguments (a)>) #<procedu?>))

159:9 2 (_ #(#(#(#<directory (gnu packages web) 7f79c17a2820> "minify") #<procedure arguments (a)>) #<procedu?>))

223:20 1 (proc #(#(#(#<directory (gnu packages web) 7f79c17a2820> "minify") #<procedure arguments (a)>) #<proc?>))

In unknown file:

0 (%resolve-variable (7 . go-github-com-tdewolff-minify-v2) #<directory (gnu packages web) 7f79c17a2820>)

ERROR: In procedure %resolve-variable:

error: go-github-com-tdewolff-minify-v2: unbound variable

My rational was to keep golang module in (gnu packages golang-web) and

the new inherited package providing executable in (gnu packages web)

which introduced the regression.

Here it is that bad boy!

Toggle snippet (18 lines)(define-public minify
  (package
    (inherit go-github-com-tdewolff-minify-v2)
    (name "minify")
    (arguments
     (substitute-keyword-arguments
         (package-arguments go-github-com-tdewolff-minify-v2)
       ((#:install-source? _ #t) #f)
       ((#:import-path _ "github.com/tdewolff/minify/v2")
        "github.com/tdewolff/minify/cmd/minify")))
    (inputs
     (list go-github-com-djherbis-atime
           go-github-com-dustin-go-humanize
           go-github-com-fsnotify-fsnotify
           go-github-com-matryer-try
           go-github-com-spf13-pflag))))

Having that all too close to my heart I've pushed revert commit

c4687f5437ad89a7e87deed1933b60f6eac83176 wich fixed CI and `guix pull`.

I've started reviewing what could be wrong and maybe the current split

process of (gnu packages golang) into logical modules e.g. golang-xyz,

golang-check, golang-crypto, golang-web introduced deep level of

circular dependencies among Guile modules.

I search for solutions to mitigate the introduced issue.

My plan is to start cleaning up dependency to (gnu packages golang) for

each recently introduced module by moving packages away from it into

groups.

I would be appreciated on any documentation link or examples in code

where package inheritance is used to source package from other module

^.^

Regards,

Oleg

Josselin Poiret wrote on 31 Jan 11:41 +0100

Recipients:

Message-ID:87msslzsxt.fsf@jpoiret.xyz

Hi Oleg,

Sharlatan Hellseher <sharlatanus@gmail.com> writes:

Toggle quote (9 lines)

> Long story short, how to resolve package inheritance which would not

> break CI ;-) ?

> [...]

> My rational was to keep golang module in (gnu packages golang-web) and

> the new inherited package providing executable in (gnu packages web)

> which introduced the regression.

Please see "(guix) Cyclic Module Dependencies" in the manual, it

contains some explanations around this kind of issue.

I'd suggest not separating inherited packages in different modules.

Best,

Josselin Poiret

Simon Tournier wrote on 1 Feb 14:27 +0100

Re: bug#68835: Resolving package inheritance issue

Recipients:

Message-ID:87v878e2mb.fsf@gmail.com

Hi,

On Wed, 31 Jan 2024 at 01:01, Sharlatan Hellseher <sharlatanus@gmail.com> wrote:

Toggle quote (4 lines)

> My rational was to keep golang module in (gnu packages golang-web) and

> the new inherited package providing executable in (gnu packages web)

> which introduced the regression.

As said by Josselin, the manual provides some explanations for this kind
of situations.

    https://guix.gnu.org/manual/devel/en/guix.html#Cyclic-Module-Dependencies

Roughly speaking, your proposal for Go language packages breaks because
more or less « Because the ‘inherit’ field is not delayed (thunked), it
is evaluated at the top level at load time, which is problematic in the
presence of module dependency cycles. »

The “fix” would to wrap it using a procedure; as explained in the
manual.  Something like:

    (define (make-minify)
      (package
        (inherit go-github-com-tdewolff-minify-v2)
        (name "minify")
        (arguments
         (substitute-keyword-arguments
             (package-arguments go-github-com-tdewolff-minify-v2)
           ((#:install-source? _ #t) #f)
           ((#:import-path _ "github.com/tdewolff/minify/v2")
            "github.com/tdewolff/minify/cmd/minify"))))
         
Well, then it is not clear for me how the user would access to this
package but somehow that’s another story. :-)x

As Josselin, I would suggest to keep in the same Guile module the
original package and its variants created using ’inherit’; well as the
general rule.

Cheers,
simon

Maxim Cournoyer wrote on 12 Feb 05:53 +0100

Recipients:(name . Josselin Poiret)(address . dev@jpoiret.xyz)

Message-ID:875xyuwaf6.fsf@gmail.com

Hi Oleg,

Josselin Poiret <dev@jpoiret.xyz> writes:

Toggle quote (18 lines)> Hi Oleg,
>
> Sharlatan Hellseher <sharlatanus@gmail.com> writes:
>
>> Long story short, how to resolve package inheritance which would not
>> break CI ;-) ?
>>
>> [...]
>>
>> My rational was to keep golang module in (gnu packages golang-web) and
>> the new inherited package providing executable in (gnu packages web)
>> which introduced the regression.
>
> Please see "(guix) Cyclic Module Dependencies" in the manual, it
> contains some explanations around this kind of issue.
>
> I'd suggest not separating inherited packages in different modules.

Agreed; using lazy evaluation to alleviate cycles is our modules is

convenient; but it means we need a strict hygiene, following what's laid

out in the referenced doc section above.

I'm closing, but feel free to discuss this further if something is not

clear/could be improved.

Thanks,

Maxim

Closed

Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it

mumi current 68835

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

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date