Bug 538290 – app-portage/elogviewer version bump to 2.3

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Mathias Laurin 2015-01-30 21:59:01 UTC]

Created attachment 395232 [details]
working (but does not enforce PyQt5 +widgets) ebuild for 2.3

That is very likely for Brian Dolbec (hi!).

As Qt4 is reaching its end of life this year, I updated
elogviewer to support PyQt5.  Note that 2.3 *adds* supports for
PyQt5 but does not *require* it so that it should *not* depend
on Qt5 stabilization #454132.

What the program requires is now one of

- dev-python/PyQt5
- dev-python/PyQt4
- dev-python/pyside

and the dependencies are nonblocking (all three libs can be
installed in which case PyQt5 is preferred).

Now, if the user has PyQt5, she *must* have installed it with
+widgets and +gui.  I do not know how to check this in an
ebuild, however, so that the ebuild attached does not enforce
the USE flags.


git history is the changelog (not much really):
	https://github.com/Synss/elogviewer/

updated program is on sourceforge:
	http://sourceforge.net/projects/elogviewer/files/elogviewer/

[Comment 1 Brian Dolbec (RETIRED) 2015-01-30 22:47:50 UTC]

KDE team, cam you recommend the best/preferred way to handle the pyQT4/5/pyside deps?

qt4/5 USE flags?  if so what about pyside? ... only if neither of the qt flags are set?

[Comment 2 Johannes Huber (RETIRED) 2015-01-30 23:10:09 UTC]

I cant figure out in upstream build sys how to enabled/disable the dependencies, looks automagic to me. The qt4/qt5  dependencies in attached ebuild maintained by qt herd. Maybe they have a better inside.

[Comment 3 Brian Dolbec (RETIRED) 2015-01-30 23:20:42 UTC]

ok, this is the relevant import section of the script:

try:
    import sip as _sip
except ImportError:
    from PySide import QtGui, QtCore
else:
    try:
        from PyQt5 import QtGui, QtWidgets, QtCore
    except ImportError:
        for _type in "QDate QDateTime QString QVariant".split():
            _sip.setapi(_type, 2)
        from PyQt4 import QtGui, QtCore
        QtCore.QSortFilterProxyModel = QtGui.QSortFilterProxyModel
        QtWidgets = QtGui

Qt = QtCore.Qt


So, yeah they are automagic.  Is there a different way that you prefer the imports/dependencies be done?

[Comment 4 Ben de Groot (RETIRED) 2015-01-31 07:42:58 UTC]

It seems this translates to 
RDEPEND=" || ( 
    dev-python/PyQt5[gui,widgets,${PYTHON_USEDEP}]
    dev-python/PyQt4[X,${PYTHON_USEDEP}]
    dev-python/pyside[X,${PYTHON_USEDEP}] )"

Unless upstream wants to make this non-automagic, that seems to me to be a decent solution.

[Comment 5 Mathias Laurin 2015-02-01 17:27:35 UTC]

Created attachment 395336 [details]
ebuild for 2.3

[Comment 6 Davide Pesavento (RETIRED) 2015-02-01 17:41:31 UTC]

(In reply to Ben de Groot from comment #4)
> It seems this translates to 
> RDEPEND=" || ( 
>     dev-python/PyQt5[gui,widgets,${PYTHON_USEDEP}]
>     dev-python/PyQt4[X,${PYTHON_USEDEP}]
>     dev-python/pyside[X,${PYTHON_USEDEP}] )"
> 

Yep, PyQt5 is preferred to PyQt4 which is preferred to pyside. In the PyQt4/5 case, a dependency on sip is needed too.

Adding a qt5 useflag doesn't seem a bad idea either...

qt5? ( sip PyQt5[gui,widgets] )
!qt5? ( || ( sip PyQt4[X] ) pyside[X] )

[Comment 7 Mathias Laurin 2015-02-01 17:50:22 UTC]

(In reply to Ben de Groot from comment #4)
> It seems this translates to 
> RDEPEND=" || ( 
>     dev-python/PyQt5[gui,widgets,${PYTHON_USEDEP}]
>     dev-python/PyQt4[X,${PYTHON_USEDEP}]
>     dev-python/pyside[X,${PYTHON_USEDEP}] )"
> 
> Unless upstream wants to make this non-automagic, that seems to me to be a
> decent solution.

I updated the build with the RDEPEND given above.

I do not want to make it non-automagic:
1. This is Python, installing the program does not build
   anything and link to the dependencies. So that it will not
   break if the user e.g. upgrades from PyQt4 to PyQt5.
2. This is how matplotlib-1.4 handles the transition to PyQt5 as
   well and if it is good enough for them, it is good enough for
   me.

[Comment 8 Brian Dolbec (RETIRED) 2015-02-01 18:03:52 UTC]

Thanks, I have it in progress, I'm also editing the other ebuilds, removing no longer supported pythons 2.6, 3.1, 3.2.

I'll be committing later today.  I'm heading out to some volunteer work atm

[Comment 9 Brian Dolbec (RETIRED) 2015-02-03 23:22:35 UTC]

Done, pushed to the tree.