On 08/18/2014 08:22 AM, Gianfranco Costamagna wrote: > Since also my first sponsor got some troubles in running them (if you > choose pyside without having it installed you will likely have a > import error and in some cases a segfault, IIRC), and since I'm a > person that _really_ likes to install and run things, rather than > install, run/fail/run/fail/check_faults/change_library, I choose to > go for having them both required.
IMHO it's perfectly reasonable that if you can select the binding engine, and the selected one is missing, the example fails. The idea of the example is not to let people swap engines at runtime, but to make the example run at all. You could detect at runtime which binding is available and "gray out" the selection if you really wanted to. This would fix the issue "permanently". > In my opinion A is the best solution (didn't come in my mind when I > firstly thought about this problem), but I really would like to hear > some feedbacks ;) I would go for a Depends: pyside|pyqt recommending pyside as the favorable option, since pyqt with python 2.7 has still the old SIP api enabled by default (and changing it is a PITA). I would recommend newcomers to use pyside if possible, even just for the API. Most developers already have a clear idea of which binding to use. I would agree with upstream here to ship with the documentation. I'm working often offline, and I've reported many bug reports trying to ship docs along with the packages and to always Suggest: the -doc package if it exists. I personally wouldn't put examples into a different package, but ship them with the documentation. Unless the examples come with extra unreasonable dependencies. In this case, the -doc can recommend *both* pyqt and pyside (that is, with 2 recommends), without affecting the main package and without requiring an extra one. I feel that a reccomends would be too strong anyway, as one of the goals of pyqtgraph is really to be interchangeable between the two. As far as an example is concerned, if it runs with the installed engine, what's the point really? > BTW I'm a quite old DM, but I'm not in the dm.txt list for this > package, so would be nice to have a sponsor for the change ;). Cannot help you here, I also need sponsors ;) -- debian-science-maintainers mailing list debian-science-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
