[bug#54938] Fw: Re: [bug#54938] [PATCH] gnu: sbcl-py4cl: Update to 0.0.0-1.2f2a008.

["Paul A. Patience" <paul@apatience.com>]

(Forwarding my message since I accidentally didn't include 54938@debbugs.gnu.org
in the "to" field.)

On Thursday, April 14th, 2022 at 13:14, Paul A. Patience <paul@apatience.com> wrote:
> On Thursday, April 14th, 2022 at 10:36, Guillaume Le Vaillant glv@posteo.net wrote:
>> Is there a reason to update only to commit 2f2a008 from September 2019
>> instead of a more recent one?
>
> The latest commit (from February 2021) has several issues originating from
> the backports from digikar99's py4cl2 package.
> For example, the py-cd function does not follow the naming scheme of py4cl,
> and also calls the inexistent pycall function (pycall is py4cl2's equivalent
> of py4cl's python-call).
>
> Further, a configuration file was introduced to configure several things,
> including the path to python and some configuration variables related to
> numpy array pickling.
> The problem is the configuration file has to be located in the same
> (writable) directory as py4cl.py, which of course causes problems with Guix.
> Technically this isn't an issue because Guix hardcodes the path to py4cl.py,
> so we could reuse *base-directory* for just the configuration file, but I think
> a better solution would be to put the configuration file into XDG_CONFIG_HOME,
> and that is probably better fixed at the source rather than in the Guix package.
>
> The test suite fails as well, perhaps due to the configuration file not being
> writable.
> I didn't investigate very much.
>
> I may submit some fixes to py4cl in the future for the issues I mentioned,
> but only if I keep using it (at the moment I am evaluating its suitability).
> Until then, the commit I've updated sbcl-py4cl to is the last before the first
> of digikar99's changes were merged.
>
> Best regards,
> Paul