How to have an optional dependency?

How to have an optional dependency?

[Tomas Volf]

[-- Attachment #1: Type: text/plain, Size: 2316 bytes --]

Hi!

I am writing a module in Guile, and I would like to have an optional dependency
on another library.  And I am not sure how to express it.  So far I found that
#:autoload can be used for it.

I have tried two approaches:

      #:autoload (guix derivations) (build-derivations
                                     derivation?
                                     derivation->output-path)
      #:autoload (guix gexp) (lower-object)
      #:autoload (guix store) (run-with-store store-protocol-error? with-store)

This works, but when I try to compile my library in environment without Guix, I
get a lot of warnings in the build log:

    ;;; Failed to autoload with-store in (guix store):
    ;;; no code for module (guix store)
    ;;; Failed to autoload run-with-store in (guix store):
    ;;; no code for module (guix store)
    ...

The build does succeed, but the spam in the logs is annoying.  The other
approach I discovered is using module-autoload!:

    (module-autoload!
     (current-module)
     '(guix derivations) '(build-derivations derivation? derivation->output-path)
     '(guix gexp)        '(lower-object)
     '(guix store)       '(run-with-store store-protocol-error? with-store))

This *also* works, but *also* leads to (different) warnings:

    wolfsden/guix/utils.scm:62:14: warning: possibly unbound variable `with-store'
    wolfsden/guix/utils.scm:62:25: warning: possibly unbound variable `%store'
    wolfsden/guix/utils.scm:63:16: warning: possibly unbound variable `run-with-store'
    wolfsden/guix/utils.scm:64:18: warning: possibly unbound variable `lower-object'
    wolfsden/guix/utils.scm:66:14: warning: possibly unbound variable `store-protocol-error?'
    wolfsden/guix/utils.scm:70:9: warning: possibly unbound variable `build-derivations'
    wolfsden/guix/utils.scm:71:20: warning: possibly unbound variable `derivation?'
    wolfsden/guix/utils.scm:72:20: warning: possibly unbound variable `derivation->output-path'

Is there a way to have a module as an optional dependency without any warnings?
For example, is there a way to convince the Guile that those specific variables
will be bound?  How do people commonly approach this?

Thanks,
Tomas Volf

--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: How to have an optional dependency?

[Maxime Devos via General Guile related discussions]

The reason (or at least, a reason) why you are seeing those warnings, is that stuff from autoloaded modules can be macros, so they might be needed during macro expansion (other reason is perhaps for optimization, dunno).

I think the best solution is to modify Guile to do something like adding a #:autoload/no-macro-no-inlining (name to be bikeshed), to be able to tell Guile more explicitly what behaviour is desired. Since #:autoload already exists, it shouldn’t be too difficult, I think. Another option: --assume-autoload-no-macro compilation argument.

>Is there a way to have a module as an optional dependency without any warnings?

I guess you could by adding a directory to your library source code with ‘fake’ (i.e. (define proc-name #false) + #:declarative? #false) Guix modules and add it to GUILE_LOAD_PATH when compiling the module (in Makefile or equivalent).

> For example, is there a way to convince the Guile that those specific variables
will be bound?  How do people commonly approach this?

They don’t (i.e. just deal with the warnings), or do something like ((module-ref (lookup-module '(guix something)) 'proc-name) arguments ...) (that’s not the actual procedure names).

It’s a bit more work up-front, but I recommend doing something like the #:autoload/no-macro-no-inlining thingie instead. Depending on compatibility concerns or lack thereof, you might not be able to _use_ it directly, but eventually Guile X.Y.E isn’t new anymore.

Best regards,
Maxime Devos