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