Bug#757645: Rationale for the change
> Il Lunedì 18 Agosto 2014 11:54, Yuri D'Elia ha scritto: > > On 08/18/2014 11:32 AM, Gianfranco Costamagna wrote: >>> 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". >> >> this needs code, and would be nice to have a patch, or to report >> upstream :) > > Yes, this is why it's probably like this anyway. Not worth the effort. > >> but my approach will avoid the extra documentation if not needed, >> someone talked about small systems ;) > > No problem with that. It's always good to have more granularity. > > Though generally speaking, you'd need examples for doing development. > > >>> 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? >> >> the point is that people like me wants to have stuff working without >> reading the READMEs, trying to search for the right dependencies, >> look at recommends/depends/suggests fields... > > I think this discussion is a bit overkill. > > I mean, you need pyqtgraph for development. > pyqtgraph needs at least *one* qt binding to work at all. > As a developer, I don't need strict dependencies to understand that. > In fact, I'm forced to use pyqt in some projects, and pyside in others. > > When pyqtgraph is pulled as a dependency, you need to make sure to pull > the least amount of dependencies for user's sake. This is why an OR > dependency is the way to go. I would revert dependencies just to fix this. > > I'm being pragmatic here. I'd expect developers to know what pyqt or > pyside mean. Maybe they don't know which one to choose, but this doesn't > make an intrinsic difference. I completely agree, this is what I committed on git so far http://anonscm.debian.org/cgit/debian-science/packages/python-pyqtgraph.git the "fixed" package is already on mentors https://mentors.debian.net/package/python-pyqtgraph and if somebody will ever fix the examples I'll be really happy to make them come back to the original place :D (since because of the -doc package this will require a NEW step) Now I'm trying to get everything work with python3 cheers, G. > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#757645: Rationale for the change
On 08/18/2014 11:32 AM, Gianfranco Costamagna wrote: >> 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". > > this needs code, and would be nice to have a patch, or to report > upstream :) Yes, this is why it's probably like this anyway. Not worth the effort. > but my approach will avoid the extra documentation if not needed, > someone talked about small systems ;) No problem with that. It's always good to have more granularity. Though generally speaking, you'd need examples for doing development. >> 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? > > the point is that people like me wants to have stuff working without > reading the READMEs, trying to search for the right dependencies, > look at recommends/depends/suggests fields... I think this discussion is a bit overkill. I mean, you need pyqtgraph for development. pyqtgraph needs at least *one* qt binding to work at all. As a developer, I don't need strict dependencies to understand that. In fact, I'm forced to use pyqt in some projects, and pyside in others. When pyqtgraph is pulled as a dependency, you need to make sure to pull the least amount of dependencies for user's sake. This is why an OR dependency is the way to go. I would revert dependencies just to fix this. I'm being pragmatic here. I'd expect developers to know what pyqt or pyside mean. Maybe they don't know which one to choose, but this doesn't make an intrinsic difference. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#757645: Rationale for the change
Hi Yuri > Il Lunedì 18 Agosto 2014 11:12, Yuri D'Elia ha scritto: > > 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". this needs code, and would be nice to have a patch, or to report upstream :) > >> 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. > changed in git :) > 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. > but my approach will avoid the extra documentation if not needed, someone talked about small systems ;) I mean, python is used in both development and deploy systems, so maybe a split is also good > 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? the point is that people like me wants to have stuff working without reading the READMEs, trying to search for the right dependencies, look at recommends/depends/suggests fields... my solution should be easily "apt-get install" friendly, with a nice difference between deploy and devel, and without requiring any kind of reading of the README.Debian documentation. anyway I don't think I would like to add some code for detecting the available engine on the system (just an import with an exception catch?) for the *only* benefit of debian distros. Upstream is so responsive about patches, so if you want to code and send upstream I'll be happy to cherry-pick and go for your solution :D cheers, Gianfranco > > >> 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 ;) > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#757645: Rationale for the change
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 ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#757645: Rationale for the change
Hi Frédéric and Yuri, First of all, thanks to you both for the bug report. In only one month is good to see people complaining and to see the increased popcon :), so thanks for using the package and for the bug report. I'll try to explain with a simple example the reason for this change: python /usr/lib/python2.7/dist-packages/pyqtgraph/examples/__main__.py the example code shows you the CLIExample window, when you can write and run easily the code, with the useful list of the examples on the left, where you can choose to force PyQt, or PySide as rendering engines. 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. Unfortunately I understand this change is good for people approaching for the first time to the package, while for code already in place is really an overread. For this reason, since I really want to fix this issue, I ask to you both how to proceed. What comes in my mind is: A) provide a python-pyqtgraph-examples with them both, and leave python-pyqtgraph have the choosable dependency qt|side (and maybe a recommend or suggest for the examples package), this will go in new, and I can catch the ball for adding a -doc package (upstream asked me to add it, I just need to tweak a little bit the package, the change should be trivial). B) revert this change, having a possible not fully working example suite (bad idea for people like me, but I'm just a clueless maintainer with no strong opinion on this) C) something that I didn't think about, but maybe possible (usually a DD comes here with a great and simple solution I didn't think about) 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 ;) 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 ;). Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
