Stumbled over this while compiling Tryton 5 client. According to Message 47158 - Tryton issue tracker it should have been removed, as this seems to be not needed/not supported anymore in python-gobject.
It is done on purpose to not duplicate generictreemodel.py.
pygtkcompat is still provided and support by python-gobject: https://gitlab.gnome.org/GNOME/pygobject/blob/master/setup.py#L1258
Let me answer with the words of the Python-Maintainers:
Comment #1 from Dominique Lxxxx <dimstar@.org> —
Please go yell loudly at upstream! Anybody using pygtkcompat in new code must
We dropped pygtkcompat back in:
Thu Sep 12 09:04:15 UTC 2013
- Drop pygtkcompat subpackage: the compatibility layer is no longer
used and causes adverse side-effects (like pulling in Gtk2,
which is not correctly introspectable, causing all kind of other
Are you SURE what they want is pygtkcompat? Aren’t they using
Gobject-Introspection by now?
Re-enabling pygtkcompat is a very bad idea
The tryton client does use GObject-introspection and does not enable pygtkcompat.
So we are ready for the future.
No, we are not: Issue 8489: tryton and pygtkcompat - Tryton issue tracker
If Tryton 5 still asks for pygtkcompat it is not completely migrated
Yes it is completely migrated. You have to learn what is enabling pygtkcompat and not just blinding grepping the source code.
I already tell you Tryton is using only GObject Introspection and does not enable pygtkcompat.
Why does it then import pygkcompat? If it is fully migrated, it would not need it.
I already explained:
I do not see the point of your obstinacy on this topic (that you do not seem to mastering).
I do Gtk development since 15 years (I even contributed to GObject). I know what I’m saying when I said we are fully ready for the future and we do not rely on legacy code.
What do you mean? There is no reason to get personal!
It is not about parsing the code, it is about running the client, and it does not run w/o compatibility layer to GTK2. Take a look at issue 8849 and 8139 - this is inconsistent.
If work on generictreemodel.py needs to be done as price of the migration to GTK3, then thats the price. Or rely on a compatibility layer that was dropped in some distros already 2013…6 years ago.
if I didn’t mess myself, we use
pygtkcompat only for having
GenericTreeModel class which is python only code, and strictly independant from Gtk version.
by the way, tryton desktop application has go away from Gtk2 compatibility layer, and only use Gtk3 interface.
if the problem is having
pygtkcompat dependency, would be possible to vendor
generictreemodel.py (LGPL) inside tryton code source ? note it has the downside to force someone the keep track of changes or manually maintain it.
on which distribution there is no more
pygtkcompat package ?
As written above, openSUSE dropped that in 2013 - obviously nobody needed it up to now.
Result is the following:
linux-bk4c:/home/test # tryton Traceback (most recent call last): File "/usr/bin/tryton", line 48, in <module> from tryton.client import main File "/usr/lib/python3.6/site-packages/tryton/__init__.py", line 7, in <module> import pygtkcompat
ModuleNotFoundError: No module named 'pygtkcompat'
-> So the problem is not of theoretical nature
Well we are not responsible if OpenSUSE does not install all the stuffs of the GObject release.
So you should ask OpenSUSE to keep pygtkcompat code in their packages. Or you must install yourself the missing part of GObject.
Sure, and nobody made you responsible.
To say it politely, a GTK3 program does not need pygtkcompat, as Python3-programs do not need 2to3.
Stopping the migration half way with the justification ‘done on purpose’ does not explain the ‘overpromised, underdelivered’ situation at all.
The migration has to be completed at a certain point in time. Until then I will drop the Tryton client from the openSUSE repositories.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.