[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#54876] [PATCH] gnu: sbcl-py4cl: Fix path to python3.
From: |
Paul A. Patience |
Subject: |
[bug#54876] [PATCH] gnu: sbcl-py4cl: Fix path to python3. |
Date: |
Tue, 12 Apr 2022 13:36:52 +0000 |
Hello,
On 2022-04-12 08:46:23-04:00, Maxime Devos wrote:
> This is most likely incorrect when cross-compiling. Do
>
> (lambda* (#:key inputs #:allow-other-keys)
> [...]
> (string-append [...] (search-input-file inputs "bin/python3") [...])
> [...])
>
> instead, such that it looks in 'inputs' instead of 'native-inputs'.
>
>
> Also, now that 'python3' is patched in, is the following still relevant:
>
> (propagated-inputs
> ;; This package doesn't do anything without python available
> (list python
>
> (I mean, does it still need to be propagated?)
So you're suggesting we call search-input-file and move the python
dependency to inputs rather than propagated-inputs?
Right, since the correct path to python3 is now hardcoded, it doesn't
need to be propagated.
One other thing we could do is move python-numpy to native-inputs.
It's required only for the tests and multidimensional array support, but
py4cl.py looks up python-numpy at runtime for the latter, and gracefully
handles the situation when it is not found.
A user could opt-in to the multidimensional array support by explicitly
installing python-numpy.
However, I'm not familiar with how Guix deals with Python module paths.
Would the python3 in sbcl-py4cl's inputs be able to find python-numpy if
only sbcl-py4cl and python-numpy are explicitly installed by the user?
Best regards,
Paul