bug#68835: Resolving package inheritance issue

[Maxim Cournoyer]

Hi Oleg,

Josselin Poiret  writes:

> Hi Oleg,
>
> Sharlatan Hellseher  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

bug#68835: Resolving package inheritance issue

[Simon Tournier]

Hi,

On Wed, 31 Jan 2024 at 01:01, Sharlatan Hellseher  wrote:

> 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

bug#68835: Resolving package inheritance issue

[Josselin Poiret via Bug reports for GNU Guix]

Hi Oleg,

Sharlatan Hellseher  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.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

bug#68835: Resolving package inheritance issue

[Sharlatan Hellseher]

Hi Guix!

> ./etc/teams.scm cc core
- g...@cbaines.net
- d...@jpoiret.xyz
- l...@gnu.org
- othac...@gnu.org
- rek...@elephly.net
- zimon.touto...@gmail.com
- m...@tobias.gr

Long story short, how to resolve package inheritance which would not
break CI ;-) ?

While reviewing and amending patch series from
 I've stabilized it on my local
checkout, which passed complete reconfigure and rebuild few times
(not...).

When I've pushed changes to 
the commit f8c2d8141efef4565d12d8247bade069889b720e broke CI
.

--8<---cut here---start->8---
In unknown file:
   6 (primitive-load-path "gnu/packages/web" #)
In ice-9/eval.scm:
619:8  5 (_ #f)
   626:19  4 (_ #)
   173:55  3 (_ #(#(#(# "minify") 
#) #))
159:9  2 (_ #(#(#(# "minify") 
#) #))
   223:20  1 (proc #(#(#(# "minify") 
#) #))
In unknown file:
   0 (%resolve-variable (7 . go-github-com-tdewolff-minify-v2) 
#)

ERROR: In procedure %resolve-variable:
error: go-github-com-tdewolff-minify-v2: unbound variable
--8<---cut here---end--->8---

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!
--8<---cut here---start->8---
(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
--8<---cut here---end--->8---

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


signature.asc
Description: PGP signature