Add breaking changes of next pythonscripting - #1826
Conversation
Signed-off-by: Holger Hees <holger.hees@gmail.com>
|
I'm not into the details of the pythonscripting binding, but i hope this can somewhat be condensed and more meaningfull. For example: |
Signed-off-by: Holger Hees <holger.hees@gmail.com>
is fixed |
| ALERT;Freebox Binding: The binding has been removed from the distribution. You should consider migrating to the FreeboxOS binding. | ||
| ALERT;JavaScript Automation: The event object in UI-based environments has been aligned with the file-based event object. Properties are now pure JavaScript types and property names have changed. Blockly users need to resave their scripts. | ||
| ALERT;JavaScript Automation: Automatic injection of the openHAB JavaScript library now allows for more fine-grained control. It is recommended to manually import required namespaces from the openhab library in file-based scripts and transformations and disable automatic injection for file-based scripts and transformations. | ||
| ALERT;PythonScripting Automation: Python "openhab.Timer" removed. Can be replaced with default Threading or Timer implementation. |
There was a problem hiding this comment.
This is just a comment, not on this PR, but on what is being done. I understand that things must break sometimes, but I don't understand why you must remove something like this. It will break every script that use it, and force them to (promptly) figure out how to use the other implementations. I think it would be much better to just document that "using the native implementations is preferred because..." than to just remove stuff.
There was a problem hiding this comment.
When thinking about it, I don't understand how native implementations can fully replace openhab.timer either. openhab.Timer can run completely independent of the script, it can run when no scripting engine is running. How can the native implementations achieve this?
There was a problem hiding this comment.
openhab.Timer was necessary, before the raw python thread cleanup was fully working. The old Timer implementation was registering a custom shutdown handler, which was cleaning/stopping the background thread. This is not necessary anymore, because graalpy itself is now correctly stopped/shutteddown (context is closed properly). So the main purpose is gone.
The leftover functionality (the trigger counter) was mostly used by me. If anyone else is still interested in that behavior, he can check the example, where exactly that is done. I believe this special use case should not be part of the main api.
That's the reason why I eliminated it.
There was a problem hiding this comment.
Ok, it sounds like I misunderstood what openhab.Timer was. I assumed that it was a wrapper for org.openhab.core.automation.module.script.action.Timer, which provides functionality that you can't do within a scripting language if the scripting engine is closed. But, maybe these are all really wrapping the Java timer?
Anyway, my main point was that I think it's better to leave something as "deprecated" than to remove it, even if better alternatives exist, so that you don't break things for people. The Graal Python add-on in OH is so new that it probably doesn't matter so much in this situation though, I guess the number of scripts that will be broken is quite small.
There was a problem hiding this comment.
Normally I agree, to mark first something as deprecated. But as you said, pythonscripting is so new and my hope was that no one is really using it. So I took the chance ;-)
It is removed since 2 month. And most people are using the latest pythonscripting next, which is already providing this cleaned API and no one was asking for it to bring it back.
There was a problem hiding this comment.
I didn't actually mean to just first mark it as deprecated. I meant to leave it as deprecated for "eternity", unless there are very good reasons why it must go 😉
|
Still, the related PR is merged. This needs to be added before next milestone |
4 participants
No description provided.