I cant install thonny-py5mode

[ruitrigo]

Hello,

I´d like to receive some help concerning the issue mentioned above.
I tried several times to install, without success.
Regards

[hx2A]

Hi, @ruitrigo ! We will do what we can to help you here.

Can we have more information about this? What kind of computer are you on?

Can you verify you are using the latest version of Thonny? I recall there was recently a pypi change that required a Thonny update.

@villares is the expert at working through these kinds of Thonny problems, and I'm sure that whatever issue you are experiencing, he's seen it before.

[villares]

Salve, @ruitrigo !

I have this step-by-step instructions here:
https://abav.lugaralgum.com/como-instalar-py5/

What is your platform? Can you post the error messages that you got?

[villares]

Rui's Thonny is crashing the back-end and getting an "ImportError: DLL load failed while importing _jpype: impssible to locate the specified module". I'll try to investigate this further with him!

[hx2A]

Thank you! Sounds like a Java install problem of some kind.

[ruitrigo]

How can I solve it? I must solve as soon as possible. Thanks Rui Trigo

…

Jim @hx2A: Thank you! Sounds like a Java install problem of some kind.

[villares]

Hi Rui, I've sent you some things to try by email, have you seen it?

[Thrameos]

Do we need to add a minimum version argument to jpype in future versions so when start jvm is called it will issue a runtime exception on old jvms?

[hx2A]

Do we need to add a minimum version argument to jpype in future versions so when start jvm is called it will issue a runtime exception on old jvms?

Hi @Thrameos ! Yes, this would be super helpful! Either throw an exception, or skip over versions below a specified version number as it searches for installed JREs on the computer.

[Thrameos]

It would be very difficult skip old versions because it isn’t possible (as far as I am aware) to determine what version a shared library is without loading it and the JVM may only be loaded once. However, I can call System.getProperty(“java.version”) and raise an error if it is less than acceptable. That would at least emit an error like RuntimeError: Version of JVM is less than minimum requested. (17.0.14<17.0.15, path=/usr/lib/jvm/java-17-openjdk-amd64/lib/server/libjvm.so) I put in the simple fix for now. If you are aware of some method of testing the JVM I can update it to skip over old versions.

[hx2A]

It would be very difficult skip old versions because it isn’t possible (as far as I am aware) to determine what version a shared library is without loading it and the JVM may only be loaded once.

I was skeptical that this would be possible, but thought that perhaps you'd know something I did not.

However, I can call System.getProperty(“java.version”) and raise an error if it is less than acceptable. That would at least emit an error like

If I add jar files to the classpath that are compiled in Java 17, and someone tries to start the JVM with an older version, would an exception first be thrown because of the jar files? Would the JVM make it far enough for you to call System.getProperty(“java.version”)?

I put in the simple fix for now.

In any case, thank you for thinking about this!

[Thrameos]

It would have to be at the start of python module level if I use the current implementation. The module would need to know what the required version of the jars and then issue an error. After all the packager knows what the jars were compiled for most of the time so they can set the minimum version. In theory I could test each of the jars on the jar path to see if they can run. But it is challenging because you can’t load a new jar with an old JVM. So I would need to unpack each jar fill, use a class explorer to see if the version of the class file is too new and then issue a warning. I have code for that in JPype so it would be doable. Alternatively, we could try to determine which jars failed to load by comparing the list of requested jar files passed from python with those that appeared the java.class.path. That would require more text processing but way less jar magic. I would be a bit worried about false alarms, but it is also doable. I would have to use a flag like “version_warning=True” so that it doesn’t present issues to those packages where there are multiple jars of which only one is expected to be picked up (happens all the time with javafx and multiple versions in path).

…

--Karl

[villares]

Hi folks! What we could gather so far:

@ruitrigo and me took a student's computer with Windows 10 Education. It had some form of Java 24.0 installed. Thonny portable with py5 pre-installed couldn't run the thonny-py5mode plug-in (the backend crashed). We tested import jpype and it failed with a warning about not being able to load a DLL. Updating jpype to 1.5.2 didn't help.

Installing a new Python env with miniconda, and then installing Thonny as a module on the py5coding env. import jpype worked, import py5 worked. Then we installed the thonny-py5mode plug-in and everything worked. So this is an "emergency fix".

I'm not very good with Windows so I can't launch this thonny-as-a-python-module-in-a-conda-env with a simple shortcut, but it works. You have to open the Ananconda PowerShell, do conda activate py5coding and then launch Thonny with thonny.

[ruitrigo]

I confirm what Alexandre mentioned and thanks for his help. Rui Trigo

[hx2A]

But it is challenging because you can’t load a new jar with an old JVM. So I would need to unpack each jar fill, use a class explorer to see if the version of the class file is too new and then issue a warning. I have code for that in JPype so it would be doable.

we could try to determine which jars failed to load by comparing the list of requested jar files passed from python with those that appeared the java.class.path. That would require more text processing but way less jar magic. I would be a bit worried about false alarms, but it is also doable

Both of these sound like more trouble than it is worth, and not a good idea if there are false alarms or anything else that takes away from the reliability of jpype. What I am doing now is I call jpype.getJVMVersion() after attempting to start and check that it is at least 17. If it isn't, I can give a specific error that guides the user towards a proper solution.

py5generator/py5_resources/py5_module/py5/__init__.py

Line 112 in 3482ed7

debug_info = py5_tools.get_jvm_debug_info()

py5generator/py5_resources/py5_module/py5_tools/jvm.py

Line 79 in 3482ed7

def get_jvm_debug_info() -> dict[str, Any]:

[hx2A]

I'm not very good with Windows so I can't launch this thonny-as-a-python-module-in-a-conda-env with a simple shortcut, but it works. You have to open the Ananconda PowerShell, do conda activate py5coding and then launch Thonny with thonny.

You probably can write a shell script for this? I am not that good at Windows scripting either.

Installing a new Python env with miniconda, and then installing Thonny as a module on the py5coding env. import jpype worked, import py5 worked. Then we installed the thonny-py5mode plug-in and everything worked. So this is an "emergency fix".

So, the same Java install, but new Python environment? Any chance there is something wrong with the Thonny portable, where it is not able to connect to Java correctly?

[villares]

So, the same Java install, but new Python environment? Any chance there is something wrong with the Thonny portable, where it is not able to connect to Java correctly?

This is something I need to investigate when I have the chance to find another Windows computer with the same problem. It could be something wrong with the portable, it is maddening it works on some computers but not on others.

I think it was initially using the "system" Java 24, after installing the thonny-py5mode plug-in it might have switched (via Thonny's JAVA_HOME env variable) to the JDK 17 installed by the plug-in. But I would have to verify all of this for sure.

[GoToLoop]

... installing the thonny-py5mode plug-in it might have switched (via Thonny's JAVA_HOME env variable) to the JDK 17...

That indeed can happen! Thonny's own local JAVA_HOME would override system's global JAVA_HOME.

After activating Thonny's "venv", we can do some checks on a terminal to verify the actual active JAVA_HOME:
https://GitHub.com/py5coding/py5generator/discussions/617#discussioncomment-12442578

... took a student's computer with Windows 10 Education.

I had no issues getting py5 or Thonny on a Win10 laptop. Maybe that "Education" edition might be the issue?

BtW. some bonus tips on how to set global JAVA_HOME variable on Windows:
https://discourse.Processing.org/t/java-library-problems/45377/2

[villares]

That indeed can happen! Thonny's own local JAVA_HOME would override system's global JAVA_HOME.

I think this "normally" happens and happened on the successful conda env based install as well, so I'm still very confused as of what is happening that is breaking the portable (which also could have had the JAVA_HOME variable set, I'd have to verify if it actually had).

[GoToLoop]

• On my Garuda Linux, I've created a venv just for py5 + thonny + thonny-py5mode and other related packages.
• I've also set a user function "thon" to activate that venv & run Thonny.
• In that venv there's a ".thonny" folder w/ a "configuration.ini" file and a "jdk-17" subfolder.
• In that file, there's a [general] section w/ an "environment = []" property, where the local JAVA_HOME is defined.
• We can also access that property via Thonny itself, by going to "Tools" -> "Options..." -> "General" tab.
• Once we clear that JAVA_HOME environment configuration, Thonny will start using the global defined JAVA_HOME.
• We can check that by going "Tools" -> "Open system shell..."
• Once on that opened terminal, we type in "python" to enter its REPL.
• Type in import py5 and then import py5_tools. And py5_tools.get_jvm_debug_info() after those 2 imports.

This is its output on my OS:

{
    'JAVA_HOME environment variable': '/usr/lib/jvm/default',
    'jvm version': (21, 0, 6),
    'default jvm path': '/usr/lib/jvm/java-21-openjdk/lib/server/libjvm.so'
}

BtW, I've deleted the subfolder "jdk-17" entirely, and my py5 sketches didn't complain when running on Thonny!