Resolving package inheritance issue

  • Done
  • quality assurance status badge
Details
4 participants
  • Josselin Poiret
  • Maxim Cournoyer
  • Sharlatan Hellseher
  • Simon Tournier
Owner
unassigned
Submitted by
Sharlatan Hellseher
Severity
normal
S
S
Sharlatan Hellseher wrote on 31 Jan 02:01 +0100
(address . bug-guix@gnu.org)
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

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
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmEeB3micIcJkGAhndtcnv/Ys0rUFAmW5nAMACgkQdtcnv/Ys
0rWl5w//QsT1xC5twokpQfFezmu/vhJNmRqfkNmoIOWHD+rZifwzw7y6nhoW+Bgb
7fdKVCt9NcI4D0zKBk5MJlivBdBsYgI7ViIJkKP3URPR5q69xMwQNo6GFEIQtZrP
m8+8e6ImvfxvQxUC7EwCpO4x2c5BvAGTBD57Op8s3k/asGIen2ktIaIfOesjadTr
UuXE+ToBGBZLeKrE0oPZr9Y7vdtgXO4cgCntayio3PlX76zEgGIkGV5mQAadsZlM
y5kYDvo9WRfxJUXoXTWWAr7V+uqLvzXyB3H3fasSVxxlCrdPsGFzE0AoTqOAQ70r
xoS+m+tKqiAjJ9PtTZls7i1ohKym2fe3HL0iAZfKVmo+L98a7qUiCMP4aYe4k32q
Z7tal7O7H8j9RCk5DaTTvDvhEG7/7N+fIAYb97yQAsFobRXSYKsljpv6Vmg6LgSr
2lGOjfbY9i1tQTXnMMPy8BtwMuHrgGtAzqESp4V2z3w2ugScw6Qgca1TWetHg5R9
0aY3NLRSXKOsgyWJjZgBCP/FRMFb+pef4WCMtfdfeSW0XKF5ytu3YSySti7Nk1G7
p13kbE5Eay1dE5y7m75JlcPgKr9Qr4jF+j0hInhp8Ycc2L0c1VL36bTyre0xiQ1M
nPTvqKbRuTlyRp6roPss4LvYsUwZpxJXv7C9KrSBrnsf6m6pgMU=
=CG9a
-----END PGP SIGNATURE-----

J
J
Josselin Poiret wrote on 31 Jan 11:41 +0100
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
-----BEGIN PGP SIGNATURE-----

iQHEBAEBCAAuFiEEOSSM2EHGPMM23K8vUF5AuRYXGooFAmW6I74QHGRldkBqcG9p
cmV0Lnh5egAKCRBQXkC5FhcaiolZC/4xSTnuGyWRCGarw96Uow7aS11oqelYFjyD
ShQvqIucpjbKvqxV+Ibsi+7ALV+ZYv+5ARaCOblihyCUcIJMsCZd9B+OdqtFoPh5
yuWfKoDAnZ6+J1qXq2cyyIsXC02zOpegMMsZZBH0dLmFOphXKETlEU6+SiIPG8uw
2Tp90jZjR9mbHIC/12wjkrEcH4MWDa4Ttyr83iIdWc/QI0SzqFR4DelQFLwsxie3
qtnNlI0/kA3tHP4oIMUagbECQM8BME6/q8eA9eIrzyR4pJiULAEDuEggfIvibQVV
wrFP0EtCSYPQLGQigbg5Gp6qVYAumK4jkAvFqxL+PgnrBjR1g0VUSc8BEsP0ewoT
WjKS96jzGUNrXtS1fxVsatES3hqNyF2IKdR6treaFo7i+yecIH+33lPKArvLoHg5
ZWONUQ5GWlckjODTvOtio7tbTe15tJ57DzYYMkljHLf0fjY9XuIErxGiibIf3GvY
xo4f3dvqN8T1l0EkmDExEbHmTtIlUMA=
=y0tB
-----END PGP SIGNATURE-----

S
S
Simon Tournier wrote on 1 Feb 14:27 +0100
Re: bug#68835: Resolving package inheritance issue
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.


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
M
M
Maxim Cournoyer wrote on 12 Feb 05:53 +0100
(name . Josselin Poiret)(address . dev@jpoiret.xyz)
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
?