[bug#57861,v2] gnu: Add ultrastar-deluxe.

Hi Maxime,

oh, I didn’t know gexp’s wouldn’t play nicely with input transformations. Fixed in v2.

Cheers,
Lars

---
 gnu/local.mk                                  |  1 +
 gnu/packages/games.scm                        | 91 +++++++++++++++++++
 .../ultrastar-deluxe-no-freesans.patch        | 31 +++++++
 3 files changed, 123 insertions(+)
 create mode 100644 gnu/packages/patches/ultrastar-deluxe-no-freesans.patch
  

Hello!

Lars-Dominik Braun <lars@6xq.net> skribis:

> +;; Lazily resolve to avoid a circular dependency.
> +(define fpc*
> +  (delay (module-ref (resolve-interface '(gnu packages pascal))
> +                     'fpc)))

I think this is unnecessary: you can just #:use-module (gnu packages
pascal) and have ‘fpc’ in ‘native-inputs’.  Everything will be fine
because ‘inputs’ is a thunked field (IOW, its evaluation is delayed).

Apart from that LGTM!

Thanks,
Ludo’.
  

Hello!

Lars-Dominik Braun <lars@6xq.net> skribis:

> +;; Lazily resolve to avoid a circular dependency.
> +(define fpc*
> +  (delay (module-ref (resolve-interface '(gnu packages pascal))
> +                     'fpc)))

I think this is unnecessary: you can just #:use-module (gnu packages
pascal) and have ‘fpc’ in ‘native-inputs’.  Everything will be fine
because ‘inputs’ is a thunked field (IOW, its evaluation is delayed).

Apart from that LGTM!

Thanks,
Ludo’.
  

On 17-10-2022 10:33, Ludovic Courtès wrote:
> Hello!
> 
> Lars-Dominik Braun <lars@6xq.net> skribis:
> 
>> +;; Lazily resolve to avoid a circular dependency.
>> +(define fpc*
>> +  (delay (module-ref (resolve-interface '(gnu packages pascal))
>> +                     'fpc)))
> 
> I think this is unnecessary: you can just #:use-module (gnu packages
> pascal) and have ‘fpc’ in ‘native-inputs’.  Everything will be fine
> because ‘inputs’ is a thunked field (IOW, its evaluation is delayed).

That's still a circular dependency.  Why import (gnu packages pascal) 
when you don't need it (e.g. when installing another, non-pascal, 
package)?  There is some bug report on the excessive dependencies among 
Guix modules with some proposed solutions.

Greetings,
Maxime.
  

On Mon Oct 17, 2022 at 2:25 PM BST, Maxime Devos wrote:
> That's still a circular dependency.  Why import (gnu packages pascal) 
> when you don't need it (e.g. when installing another, non-pascal, 
> package)?  There is some bug report on the excessive dependencies among 
> Guix modules with some proposed solutions.

Wouldn't using #:autoload be a cleaner way that still lazily resolves the variables?

    -- (
  

On 17-10-2022 15:28, ( wrote:
> On Mon Oct 17, 2022 at 2:25 PM BST, Maxime Devos wrote:
>> That's still a circular dependency.  Why import (gnu packages pascal)
>> when you don't need it (e.g. when installing another, non-pascal,
>> package)?  There is some bug report on the excessive dependencies among
>> Guix modules with some proposed solutions.
> 
> Wouldn't using #:autoload be a cleaner way that still lazily resolves the variables?
> 
>      -- (

Possibly, I proposed this in
<https://issues.guix.gnu.org/54539#28>.  I tried this in 
<https://issues.guix.gnu.org/54539#62> for a few package modules, with a 
relatively small but noticable improvement (presumably it would be more 
improved by doing it for all package modules instead of only a selection 
and presumably it would be more noticable on a spinning disk instead of 
an SSD).

Greetings,
Maxime.
  

Maxime Devos <maximedevos@telenet.be> skribis:

> On 17-10-2022 10:33, Ludovic Courtès wrote:
>> Hello!
>> Lars-Dominik Braun <lars@6xq.net> skribis:
>> 
>>> +;; Lazily resolve to avoid a circular dependency.
>>> +(define fpc*
>>> +  (delay (module-ref (resolve-interface '(gnu packages pascal))
>>> +                     'fpc)))
>> I think this is unnecessary: you can just #:use-module (gnu packages
>> pascal) and have ‘fpc’ in ‘native-inputs’.  Everything will be fine
>> because ‘inputs’ is a thunked field (IOW, its evaluation is delayed).
>
> That's still a circular dependency.  Why import (gnu packages pascal)
> when you don't need it

That’s what every package module does.

We can discuss the drawbacks of this and ways to avoid it, but this
particular patch and review is not the right place to do that IMO.

Thanks,
Ludo’.
  

On 17-10-2022 18:44, Ludovic Courtès wrote:
> Maxime Devos <maximedevos@telenet.be> skribis:
>[...]
>> That's still a circular dependency.  Why import (gnu packages pascal)
>> when you don't need it
> 
> That’s what every package module does.
> 
> We can discuss the drawbacks of this and ways to avoid it, but this
> particular patch and review is not the right place to do that IMO.

I tried to do that, in https://issues.guix.gnu.org/54539, but there were 
no further responses.

Greetings,
Maxime.
  

Hi Ludo and Maxim,

> I think this is unnecessary: you can just #:use-module (gnu packages
> pascal) and have ‘fpc’ in ‘native-inputs’.  Everything will be fine
> because ‘inputs’ is a thunked field (IOW, its evaluation is delayed).
the problem is that `make` fails with an error in that case. For me it’s

    ice-9/eval.scm:293:34: error: gash: unbound variable
    hint: Did you forget a `use-modules' form?

but YMMV. With #:autoload `make` succeeds, but throws similar
errors/warnings(?) in the process:

    ;;; Failed to autoload fpc in (gnu packages pascal):
    ;;; Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (fpc (gnu packages pascal)) #f)'.

That’s why I went for the route implemented in the initial patch. What
do we do now?

Lars
  

On 18-10-2022 09:56, Lars-Dominik Braun wrote:
> [...]
> the problem is that `make` fails with an error in that case. For me it’s
> 
>      ice-9/eval.scm:293:34: error: gash: unbound variable
>      hint: Did you forget a `use-modules' form?
> 
> but YMMV. With #:autoload `make` succeeds, but throws similar
> errors/warnings(?) in the process:
> 
>      ;;; Failed to autoload fpc in (gnu packages pascal):
>      ;;; Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (fpc (gnu packages pascal)) #f)'

Don't know what's up with that, maybe when compiling (gnu packages 
pascal) is imported anyway because 'fpc' might be a macro?

But if I try that in a REPL:

(define-module (foo) #:autoload (bar) ( baz))
;;; Failed to determine exported bindings from module (bar):
;;; no code for module (bar)
;;; Failed to determine exported bindings from module (bar):
;;; no code for module (bar)
$1 = #<directory (foo) 7f31caf71820>

I get other messages (warnings, in this case), so maybe an incorrect 
hypothesis.

> 
> That’s why I went for the route implemented in the initial patch. What
> do we do now?

I think the issue is that (gnu packages pascal) imports (gnu packages 
commencement), even though according to the comment in (gnu packages 
commencement), you aren't supposed to do that (because of cycles).

You could give doing the resolve-module trick in (gnu packages pascal) a 
try.

Greetings,
Maxime
  

(To add to my previous reply):

It appears that other package modules may need a similar change, 
according to a "git grep -F":

gnu/packages/engineering.scm:  #:use-module (gnu packages commencement)
gnu/packages/instrumentation.scm:  #:use-module (gnu packages commencement)
gnu/packages/pascal.scm:  #:use-module (gnu packages commencement)
gnu/packages/raspberry-pi.scm:  #:use-module (gnu packages commencement)

Alternatively, importing commencement could be accepted though the 
indirect dependency on 'games' from 'commencement' may need to be broken 
to resolve the error (?) message,  as done in 
<https://issues.guix.gnu.org/54539#62>

I don't remember if (gnu packages games) was one of the modules that was 
removed from the dependencies, though, and I'm not sure if this change 
would resolve things here.

Greetings,
Maxime.