| Message ID | 20220414140746.34334-1-paul@apatience.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#54938] gnu: sbcl-py4cl: Update to 0.0.0-1.2f2a008. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/applying patch | fail | View Laminar job |
| cbaines/issue | success | View issue |
"Paul A. Patience" <paul@apatience.com> skribis: > * gnu/packages/lisp-xyz.scm (sbcl-py4cl): Update to 0.0.0-1.2f2a008. > [arguments]<#:phases>: Adjust substitutions to renamed files. > --- > gnu/packages/lisp-xyz.scm | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/gnu/packages/lisp-xyz.scm b/gnu/packages/lisp-xyz.scm > index 29b3a10d98..bd68814aca 100644 > --- a/gnu/packages/lisp-xyz.scm > +++ b/gnu/packages/lisp-xyz.scm > @@ -5152,8 +5152,8 @@ (define-public ecl-find-port > (sbcl-package->ecl-package sbcl-find-port)) > > (define-public sbcl-py4cl > - (let ((commit "4c8a2b0814fd311f978964f825ce012290f60136") > - (revision "1")) > + (let ((commit "2f2a008dd6162d4446803971292fe1b323fe0dd5") > + (revision "2")) > [...] Hi, Is there a reason to update only to commit 2f2a008 from September 2019 instead of a more recent one?
(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
"Paul A. Patience" <paul@apatience.com> skribis: > (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 Ok, thanks for the explanation. Patch pushed as 5059e7f01e1d299a2a52b1649251fa49f1992385.
diff --git a/gnu/packages/lisp-xyz.scm b/gnu/packages/lisp-xyz.scm index 29b3a10d98..bd68814aca 100644 --- a/gnu/packages/lisp-xyz.scm +++ b/gnu/packages/lisp-xyz.scm @@ -5152,8 +5152,8 @@ (define-public ecl-find-port (sbcl-package->ecl-package sbcl-find-port)) (define-public sbcl-py4cl - (let ((commit "4c8a2b0814fd311f978964f825ce012290f60136") - (revision "1")) + (let ((commit "2f2a008dd6162d4446803971292fe1b323fe0dd5") + (revision "2")) (package (name "sbcl-py4cl") (version (git-version "0.0.0" revision commit)) @@ -5166,7 +5166,7 @@ (define-public sbcl-py4cl (file-name (git-file-name name version)) (sha256 (base32 - "15mk7qdqjkj56gdnbyrdyz6r7m1h26ldvn6ch96pmvg5vmr1m45r")) + "1zx1kpfpd8mi1qaa7gr32mki6nvl6pqcs3437fvn4xa3yf7ybsha")) (modules '((guix build utils))))) (build-system asdf-build-system/sbcl) (native-inputs @@ -5181,7 +5181,7 @@ (define-public sbcl-py4cl (modify-phases %standard-phases (add-after 'unpack 'fix-python3-path (lambda* (#:key inputs #:allow-other-keys) - (substitute* "src/callpython.lisp" + (substitute* "src/python-process.lisp" (("\\*python-command\\* \"python\"") (string-append "*python-command* " "\"" @@ -5194,7 +5194,7 @@ (define-public sbcl-py4cl ;; source-code so lisp can call into "py4cl.py". We can ;; hard-code this since we know where this file will ;; reside. - (substitute* "src/callpython.lisp" + (substitute* "src/python-process.lisp" (("py4cl/config:\\*base-directory\\*") (string-append "\""