Bug#757645: Rationale for the change

Gianfranco Costamagna costamagnagianfranco at yahoo.it
Mon Aug 18 09:32:21 UTC 2014


Hi Yuri



> Il Lunedì 18 Agosto 2014 11:12, Yuri D'Elia <wavexx at thregr.org> 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 ;)
> 



More information about the debian-science-maintainers mailing list