Jython is not deprecated

I personally think it would be better. The JS Scripting add-on I would hope is enough of an example to show how to do everything necessary to make it work.

Based on my experience with JS, I suspect that GraalVM Python might have better support for pypy modules (not that you can’t use pip with Jython, but it was always somewhat awkward). And of course it supports Python 3 as well which is a bonus. If it supports venvs that would be best since bookworm disabled the ability to install Python modules globally except through apt.

But I’m just happy there is any work being done on a Python add-on.

I’m already working on it in parallel. But I need time to explore and play with it.

A prototype already exists, using the org.netbeans.api, because the graal python does not provide a script engine. Maybe it will only work, when openhab is running on java 21.

but again, for now it is more or less a useless playground, to get some experiences with it.

My goal is to improve, maintain and update jython until we have a working graalpython solution.

6 Likes

This pull request replaces the previous one, which I closed due to a mistake :innocent:

3 Likes

I’m really happy to see this being worked. Thank you for taking it on!

to give a status update. My pull request was accepted and is merged into 4.2 milestone branch.

I added myself also to the CODEOWNERS file and hope that I will be accepted there too :slight_smile:

6 Likes

If anyone is interesting to using the new jar.

https://github.com/HolgerHees/openhab-config/raw/master/addons/org.openhab.automation.jythonscripting-4.2.0-SNAPSHOT.jar

it is compiled for openhab 4.2 but works in openhab 4.1 as it is. It is running in my openhab 4.1 production env without any noticeable problem.

documentation regarding changed python paths (/automation/jython/ & /automation/jython/lib) can be found here.

2 Likes

A great way to help users test an add-on is to post it to the marketplace. That lets users install it through MainUI instead of downloading a jar file. It also centralizes your troubleshooting and conversation and shows the maintainers that it’s been tested by third parties.

It will also show users that Jython is back under active development.

1 Like

Fantastic, @holger_hees! Even though I’m not a python guy, I’m excited to see someone start to maintain it again. And you’re getting into it perfectly - small baby steps to gain familiarity with the codebase yourself, and credibility within the community.

I’m not on the forums as much as @JimT is, but be sure to ping us both if you need to bounce any ideas off us of for helper library design.

I definitely agree with @rlkoshak that users will generally be happier if you make it as Python-first as possible. While there are some users that choose a non-visual and non-DSL language for rules essentially at random, I feel like most choose an alternate language specifically because they already know that language and don’t want to learn/care about Java-isms or the internals of openHAB. And I know there are a lot of Python people in the IoT community at large.

One last thing I would note is to not get frustrated if a PR takes a long time to get reviewed. The core maintainers have a very limited time, and many many potential contributions coming at them. Just politely ping one or the group of them every couple weeks if there hasn’t been any activity (I need to go do that on one of my PRs!). Eventually they’ll get to it. I think my record is 2 years of a PR sitting there.

6 Likes

I have issues after updating 4.2.0.M1 to 4.2.0.M2.

I get ERROR’s for all imports in my python scripts, like:

024-04-09 18:19:49.555 [INFO ] [ort.loader.AbstractScriptFileWatcher] - (Re-)Loading script '/etc/openhab/automation/jsr223/python/personal/300_common_daytime.py'
2024-04-09 18:19:50.077 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - Error during evaluation of script '/etc/openhab/automation/jsr223/python/personal/300_common_daytime.py': ImportError: No module named core in /etc/openhab/automation/jsr223/python/personal/300_common_daytime.py at line number 5

My imports (similar in all file based scripts):

from core.rules import rule
from core.triggers import when
from core.log import logging, LOG_PREFIX
from core.actions import Transformation
from datetime import datetime, timedelta, date, tzinfo
from core.date import format_date

Downgrading to M1 resolves the issue.

Hi,

you must change your python lib path from /etc/openhab/automation/lib/python to /etc/openhab/automation/jython/lib

the old legacy configuration was

python libs: $OPENHAB_CONF/automation/lib/python
python rules: $OPENHAB_CONF/automation/jsr223

the new unified configuration is

python libs: $OPENHAB_CONF/automation/jython/lib
python rules: $OPENHAB_CONF/automation/jython

it is already documented here

but should be mentioned in breaking changes too, before the final release.

1 Like

Great job @holger_hees.
Installed 4.2.0.M2, had about 900 lines of rules, moved the rules and old helper libraries to their new locations, been running for a couple of days, everything works great.
Thanks for reviving jython!

I noticed you have your own repository of helper libraries inspired from the old ones, is this something to look forward to in the future?

yes, I will refactor my repository and split it into a core and custom part. The core part will be hopefully integrated into the jython binding.

currently I evaluate what could be the best way to do it. Means I research and evaluate other api’s to get a opinion about, how to do it. I’m also open for other opinions, how a good api should look and what is needed and what should be not included. It should not be a api which encapsulate everything. I will avoid that the code will be to complex. The api should be simple and enough to do everything else by your own.

Inside my core file (excluding the UserHelper and NotificationHelper class) is everything what I needed the last 10 years and what could be the base for the new api.

I am very excited, that there seems to be some hope for Python rules in openHAB!

@holger_hees Thanks a lot for your work!

I only found this thread after I too encountered the “ImportError: No module named core” error after upgrading to the latest milestone (yes, I should have read the release notes more carefully…). I moved my rules and the lib to the new location, as documented here and everything seems to work, currently I am doing some more testing!

I would like to suggest to add the changed locations to the “Listing important changes for version 4.2.0” section, which is displayed after upgrading via apt.

1 Like

I also just upgraded from M4.2.0-M1 to M4.2.0-M2 today and my jython rules totally broke. I am using the long Un-touched jython helper libraries, but up until today everything worked fine. My jython scripts are dependent on the helper libraries. Are there instructions somewhere that explain where to move all of those various libs, and my personal scripts, to get me going again?

I tried reverting to M1 but there was no change in behavior (I think that is because the add on already updated to the new one.) I was surprised there wasn’t more of a warning about this!

Lastly, I also noticed that the add-on store page seems to be broken. Or corrupted, has anyone else seen this?

You habe to move the helper libs and the rules, see

1 Like

I added a “breaking change” info to the upcoming release notes too.

Thank you for the replies! I tried it this morning quickly, but I’m still downgraded to M1 so it didn’t work. This afternoon I will upgrade back to M2 and hopefully it will work. However one question I have is: do I leave all the helper libraries in their folder structure (like core, community, personal) and then move that structure into ‘lib’, and then in the root jython folder can I have a community and personal folder? Thank you!

@stagf15 yes

in /automation/jython you can put all your rule scripts and in /automation/jython/lib you can put your libraries including their folder structure.

the reason for that change is to align the folder structure with other scripting addons like javascript, ruby or groovy etc.

/automation/js/
/automation/ruby/
/automation/groovy/

later, there will be a /automation/python/ too, but this is reserved for the graalvm based version of python addon in the future.

1 Like

Thank you all for your help. I re-upgraded to M2 just now and after a lot of loading and one OpenHAB crash everything seems to be running well. From what I can tell it doesn’t matter what the directory structure is as long as any library is inside lib (it can be in any directory inside lib though) and any script is not in lib (it can be in any directory that’s not in lib).

Like I said earlier, I’m still using the helper libraries, and I mentioned a problem several months ago and I’m wondering if you know of a fix… The directory watcher trigger doesn’t seem to be working and throws an error. This (I believe) was at the change to OH4 and Java 17. Have you implemented a fix in the helpers, or in your fork of them?

Thank you again!

no,

I’m not maintaining the old helper libraries. I have also not implement a fix for it, because I don’t use the directory watcher. Instead I’m implementing a new version of the libraries which will be be a refactored, cleaned and simplified version of the old helper libraries. Or better, its not a new version of the old helper libraries, instead it is just inspired by the old helper libraries where I ask myself for every feature if this is really necessary or if there is a better way to do it.

but you could send me a link to your original post where I can see your error message. Maybe I can give you a hint, how to fix.