2020-03-03, 16:15
thats what they called double work
2020-03-03, 17:49
just as a sidenode: all of our skinners have to update their skin each and every kodi release.
some skinners maintain three versions of their skins (kodi 17 / kodi 18 / kodi 19)
somehow none of them ever complain....
some skinners maintain three versions of their skins (kodi 17 / kodi 18 / kodi 19)
somehow none of them ever complain....
2020-03-03, 17:58
(2020-03-03, 17:49)ronie Wrote: just as a sidenode: all of our skinners have to update their skin each and every kodi release.skin is skin, addon is addon two different things what you think
some skinners maintain three versions of their skins (kodi 17 / kodi 18 / kodi 19)
somehow none of them ever complain....
2020-03-03, 18:30
@ronie: I think my complain is legit, all the add-ons I work on are Py2/Py3 compatible and there was a lot of time invested to do so.
How hard can it be to make sure that addon.xml is also Py2/Py3 compatible so that add-on developers can submit a Py2/Py3 compatible add-on just once?
In my opinion the release of Kodi 19 should be postponed until Py2/Py3 compatibility in addon.xml is implemented the right way!
How hard can it be to make sure that addon.xml is also Py2/Py3 compatible so that add-on developers can submit a Py2/Py3 compatible add-on just once?
In my opinion the release of Kodi 19 should be postponed until Py2/Py3 compatibility in addon.xml is implemented the right way!
2020-03-03, 23:19
(2020-03-03, 18:30)mediaminister Wrote: How hard can it be to make sure that addon.xml is also Py2/Py3 compatible so that add-on developers can submit a Py2/Py3 compatible add-on just once?
we've been trying to find someone who could implement that for over two years now... so my answer would be it is very hard.
(2020-03-03, 18:30)mediaminister Wrote: In my opinion the release of Kodi 19 should be postponed until Py2/Py3 compatibility in addon.xml is implemented the right way!
i beg to differ. frankly my opinion is that team kodi should have made sure kodi 19 was released before python 2 went end-of-life.
when a user installs kodi today, we install an unmaintained version of python with it... and that potentially opens up the users system to exploits.
it's not a situation i'm particularly proud of, and imo we should get v19 out of the door as quickly as possible.
2020-03-05, 00:49
It would have made sense to announce such a hard break at the Kodi 18 release rather than having devs waste a lot of time making the code py2&3 compatible (as was requested and required) and then flagging all these compatible addons as incompatible anyway.
On my Kodi19 installation, 41 addons are now deemed incompatible and have been forcefully disabled, even though almost all of them were working absolutely fine. Kodi doesn't let me enable them either. Rather than forcefully blocking them, there should be a way to at least manually reactivate them while displaying a warning that they may not work as expected. Or as suggested above, add an addon.xml attribute to mark compatible addons as py2&3 compatible and only disable addons that require py2 and do not have this flag. Addons requiring py3 don't need that flag and are fine anyway. This avoids having to maintain multiple versions of exactly the same codebase, submitted to multiple branches and avoids the mess.
I've picked up and worked on quite a few unmaintained addons and made them py3 compatible, then spent more time re-adding py2 support for the current Kodi18 users and now all of them stopped working again.
On my Kodi19 installation, 41 addons are now deemed incompatible and have been forcefully disabled, even though almost all of them were working absolutely fine. Kodi doesn't let me enable them either. Rather than forcefully blocking them, there should be a way to at least manually reactivate them while displaying a warning that they may not work as expected. Or as suggested above, add an addon.xml attribute to mark compatible addons as py2&3 compatible and only disable addons that require py2 and do not have this flag. Addons requiring py3 don't need that flag and are fine anyway. This avoids having to maintain multiple versions of exactly the same codebase, submitted to multiple branches and avoids the mess.
I've picked up and worked on quite a few unmaintained addons and made them py3 compatible, then spent more time re-adding py2 support for the current Kodi18 users and now all of them stopped working again.
2020-03-05, 01:08
Hi I develop an unofficial plugin that doesn't even go through the Kodi repo that no longer works. It is a specialty addon used by a handful of users and how does it makes sense for Kodi to demand a minimum version which in fact is not actually correct since te addon works fine with python2 in v18 and with python 3 up to now. If Kodi wants to control the official repository that it fine but why does this need to apply to unofficial addons?
Martin
Martin
2020-03-05, 01:52
ISTM in the long or even medium run, it's easier to maintain separate addons rather than try to maintain 2/3 compatibility (unless you do something like if py2 do this, if py3 do that which amounts to separate addons combined into one). If the addon is truly 2/3 compatible, then the only difference is addon.xml?
scott s.
.
scott s.
.
2020-03-05, 02:54
With separate versions you also need separate repositories, you can't submit a PRs to existing addons without either breaking backwards compatibility to the current release version of Kodi, not supporting Kodi 19 by maintaining the py2 requirement, requiring the maintainer to create a separate branch and/or forking completely and possibly ending up with various versions all over the place.
The kodi team decided 2 years ago to require py2&3 compatibility and there are good reasons for it. Requiring separate versions now after the work has been done to fix the compatibility issues, doesn't make sense.
I could have saved a lot of time not learning how to keep the py2 versions working and only concentrated on py3.
The kodi team decided 2 years ago to require py2&3 compatibility and there are good reasons for it. Requiring separate versions now after the work has been done to fix the compatibility issues, doesn't make sense.
I could have saved a lot of time not learning how to keep the py2 versions working and only concentrated on py3.
2020-03-05, 04:29
(2020-03-05, 01:52)scott967 Wrote: If the addon is truly 2/3 compatible, then the only difference is addon.xml?
All the addon.xml files for all support libraries also have to be bumped. For my case I still need to wait for newer kodi-six (github version works but it is still 1.1.3 which might need a bump to guarantee updates) and I also had to update the requirement in my addon.xml to point to a newer version of script.module.dateutil which uses python 3.0.0.
Martin
2020-03-09, 13:42
One final version to support for a short while... either way python3 is the future
2020-03-18, 10:49
There is still great confusion for me regarding this change which makes it impossible for me to customize add-ons for use with Kodi 19 Matrix.
What's the best practice regarding version numbers for Py2/3 compatible add-ons that should work flawlessly for existing users using Kodi 18 who will eventually upgrade to Kodi 19?
What's the best practice regarding version numbers for Py2/3 compatible add-ons that should work flawlessly for existing users using Kodi 18 who will eventually upgrade to Kodi 19?
