This is largely resolved now - turns out my code sucked rather than needing
to do something clever with Guix module importing, which is what I
suspected ;-)
The only compromise I'm making now is that any complicated manifest for
example, I am having to split into a trivial manifest script calling into a
library that I can then unit test - so it's not quite as good as having a
meta switch for manifests or repl scripts, but it's good enough.
On Sun, 13 Feb 2022 at 20:58, Phil <p...@beadling.co.uk> wrote:
> I have a theory about what is causing this - I think it's me not thinking
> about deferred evaluation carefully enough.
>
This is true, but my second post was still missing the point!
>
> What I think is happening is that the propagated-inputs in my newly
> created test-package will have their evaluation delayed until the build
> occurs in the daemon. I presume at this point my local library I've used
> add-to-load-path to include in the manifest will no longer be accessible
> and hence the eval failure being returned.
>
>
>
The problem was actually much easier to solve than I had originally
over-thought - simply by making my-package- with-my-gurobi a procedure
which returns the package rather than having it defined as a variable that
contains a package all the problems go away apart from a handful of imports
required in the library script. The my-gurobi-package can also be nested
inside the let statement, and the whole procedure added to the library.
(define (my-package-with-my-gurobi)
(let* ((test-package-string (get-env-var-or-prompt "GUIX_TEST_PACKAGE"))
(test-package (specification->package test-package-string))
(my-gurobi-package ((transform) (specification->package
"gurobipy"))))
(format #t "~%Setting Test Package: ~a~%" test-package-string)
(package/inherit test-package
(propagated-inputs
`(("gurobipy" ,my-gurobi-package) ;; add my new gurobi
,@(alist-delete "gurobipy"
(package-propagated-inputs test-package))))))) ;; remove the original
gurobi and splice
