Matrix of setups that work

[mikub]

Hi everybody! Amazing project, I am still mind blown that this exists!

However upon trying to initialize I am running into:

Execution error (IllegalAccessError) at libpython-clj.python.object/apply-method-def-data! (object.clj:417).
tried to access class com.sun.jna.CallbackReference from class libpython_clj.python.object$apply_method_def_data_BANG_

I have tried both 1.46 and 2.00-alpha-6 with the same result (for 1.46 it only differs in line number, i.e. object.clj:419).

My env is Linux Mint, tried with python 3.5 and 3.6 and currently on JVM 1.8. I also tried on few vanilla VMs/containers and I will continue with trying different JVM versions.

This brought me to this question: to avoid reporting issues for every particular setup possible, do we have somewhere some matrix of configurations that are guaranteed to work?

E.g.:

OS	Java	Python	Anaconda?	libpython-clj	Works	Known issues
Linux Mint 18.1	openjdk version "1.8.0_131"	3.6	No	1.46	No	#142

Ideally there would be a line or two like this: e.g. when using Java 14 and Ubuntu xxx and Python 3.6 and libpython-clj 1.46 this is guaranteed to work...

This would help tremendously with the setup, I could just spin off some VM and would be guaranteed that this would work...

Thanks heaps for any help Cheers

Miro

---

For sake of completeness here is whole print from REPL

(require '[libpython-clj.python
           :refer [as-python as-jvm
                   ->python ->jvm
                   get-attr call-attr call-attr-kw
                   get-item att-type-map
                   call call-kw initialize!
                   as-numpy ->numpy
                   run-simple-string
                   add-module module-dict
                   import-module
                   python-type]])
=> nil
(initialize! :python-executable "/usr/bin/python3.6")
 INFO [nREPL-worker-1] - Executing python initialize with options:{:python-executable "/usr/bin/python3.6", :program-name nil, :python-home nil, :library-path nil}
 INFO [nREPL-worker-1] - Detecting startup-info for Python executable: /usr/bin/python3.6
 INFO [nREPL-worker-1] - Startup info detected:
{:lib-version "3.6",
 :java-library-path-addendum "/usr/lib",
 :exec-prefix "/usr",
 :executable "/usr/bin/python3.6",
 :libnames ("python3.6m" "python3.6"),
 :prefix "/usr",
 :base-prefix "/usr",
 :base-exec-prefix "/usr",
 :python-home "/usr",
 :version [3 6 12],
 :platform "linux"}

 INFO [nREPL-worker-1] - Trying python library names ["python3.6m" "python3.6" "python3.7m" "python3.6m"]
 INFO [tech.resource.gc ref thread] - Reference thread starting
 INFO [nREPL-worker-1] - Library python3.6m found at [:system "python3.6m"]
Execution error (IllegalAccessError) at libpython-clj.python.object/apply-method-def-data! (object.clj:417).
tried to access class com.sun.jna.CallbackReference from class libpython_clj.python.object$apply_method_def_data_BANG_

Process finished with exit code 137 (interrupted by signal 9: SIGKILL)

[jjtolton]

Hi @mikub! I agree it would be tremendously helpful to have that matrix. Maybe using clj-testcontainers there might be a way to do that efficiently? Regarding your specific issue, I typically use Linux Mint and Python 3.7, which is just what I have lying around, although it also works for me with 3.6. I have a feeling there is some kind of environmental issue that might be affecting your code execution. Happy to work through it here or also feel free to leverage the community over on Zulip if you would like syncronous help.

Here are our reference installations.

[cnuernber]

@mikub - this is a result of the jna library version conflict. My guess is some other package is pulling in a version of the jna system that is not the same as specified by the libpython-clj project dependencies.

[mikub]

Thanks @cnuernber! Will check my dependency tree. In terms of Java versions should I expect different behavior say in 1.8 vs 14 or it shouldn't matter at all?

[cnuernber]

I think 14 at this point will not work as they disabled the bytebuffer constructure that we need to use from a pointer value.

8,11 should work.

[mikub]

@cnuernber indeed it was just a good old jar hell, got it working after excluding a sneaky jna from one other dependency!

So since this was not JVM related (I thought this had something to do with reflection), is it safe to assume my original point (environmental matrix) is a moot point since this should be pretty much working on JVM 1.8 -> 11 and if I understand correctly from docker files also Python 3.6-3.9 at least?

I will close the issue and if anyone feels we would still need the matrix feel free to reopen. I would imagine that the ultimate outcome of the matrix would be some more complex CI/CD Travis setup.