[PyKDE] PyKDE for sip 3.5 and 3.6

[Gerard Vermeulen]

On Fri, 18 Apr 2003 09:47:34 -0700 (PDT)
Jim Bublitz <jbublitz at nwinternet.com> wrote:

> On 18-Apr-03 Gerard Vermeulen wrote:
[ snip ]
> >> > I also suggest that build.py exits with an error message if it
> >> > discovers a Qt version that post-dates the sip files (or at
> >> > least a warning that things may not go as expected).
> 
> > Here I had in mind PyQt's build.py, in the end it will save time
> > if it complains about Qt and Python (I have a report from
> > somebody trying to build PyQt-3.5 with Python-2.3a1) that are
> > not yet supported. In the end it will save time. I also used to
> > check if PyQt and sip are compatible (I have seen that too). 
> 
> I don't believe there's an easy way to check which version of sip
> was used to build PyQt (please correct me if I'm wrong - I'd be
> happy to test for that).
>
Require that the output of
sip -V
corresponds with the output of
python -c 'from qt import *; print PYQT_VERSION'
(this still works with 3.5).
The problem is what to with snapshots: that is the reason for 'used
to check'.
>
> Consistency checks (when possible) should always work. Your other
> example (Python 2.3a1) is a harder problem. If build.py refuses to
> build with "future" versions, then there's a problem in the case
> where the PyQt/PyKDE build *would have* worked with a new version.
> I've made PyKDE "looser" for that kind of situation. Maybe the
> solution is to be more restrictive, but allow people to "force" a
> build or provide an easy method of patching build.py's version
> limits. Then it's just a matter of dealing with users who don't read
> the docs (like me). 
>
Well, I think that from a psychological point of view it is better to
have a proud user saying that they 'fixed' my build tools and that
PyQwt works with Python-5.0 than an unhappy message 'it does not
build with Python-5.0'.
Anyhow, a warning 'you are moving into unexplored territory: RTFM or
you will die' is  better than g++ dying after 30 minutes of compilation
with an cryptic error message (some people have tried days before writing
to the list).

[ snip ]
> > Ricardo has proposed to do more intermediate releases. Since sip
> > and the sip files evolve together, I do not like the idea
> > because it makes maintaining PyQwt harder (and PyQwt is much
> > smaller/simpler than PyKDE but I would like to keep PyQwt
> > compatible with several sip/PyQt versions, if possible). 
> 
> I agree there too - that's one reason why I've been investing a lot
> of time in making maintenance easier (automating development and
> adding unit testing). I don't know if any of that will be of help
> to you, and it's kind of a mess for anything besides PyKDE at the
> moment - another job in the queue.
>
> I've been lucky in that I haven't had to worry at all about Qt
> versions (only sip versions) - I think the KDE people and their
> close relatioship with TT takes care of that for me. I haven't
> looked at PyQwt closely, but I would bet it's more of a maintenance
> problem than PyKDE is. PyKDE is just big, but it's not very
> complicated (once you get it working in the first place). I write
> very little code directly for PyKDE - it's mostly an exercise in
> translating h files to sip files.
>
Qwt is a small, slow moving project compared to KDE with one
principal author and 3 others (since PyQwt exposes some bugs, I am now
allowed to fix things in CVS, too). There is maybe a little bit more
non-Qt-like use of C++ in Qwt than in KDE, but your tools may be helpful.
>  
> > Another idea is to upgrade only PyQt's sip files, if a new Qt
> > release comes out (of course it is more work for Phil).
> 
> I'm not sure what you mean here. 
>
Well, with 3.6 around the corner there is no immediate need,
but in the future it may be worthwhile to backport sip files adapted
to post-3.6-Qt-releases from post-3.6-snapshots to make a 3.6.1 release.

At least 50 % of recent mailing list traffic is related to incompatibilities
between PyKDE-3.5-2 and PyQt/sip snapshots provoked by post-3.5-Qt-releases.

Backporting from snapshots to PyQt-3.5 would have saved the world time,
but maybe not for Phil :-/

And if Phil does not want to do it: a volunteer may want to earn some fame :-)

Gerard