[PyKDE] PyKDE for sip 3.5 and 3.6

[Jim Bublitz]

On 18-Apr-03 Gerard Vermeulen wrote:
> I did not try to build PyKDE myself (I am an old-fashioned guy
> who thinks that KDE eats to many resources), 

I have a hard time reconciling how much Z80 code would fit in a 4K
EPROM with the fact that my computer with 512MB still swaps
occasionally.

> but I am stealing code  from it for PyQwt -- thanks.

That's the nicest compliment I've had in a while. Your posts here
have been very helpful too.
 
> The installation problems that some people encounter may form a
> real obstacle to the acceptance of PyQt (and PyKDE), even if it
> is due to bugs in Qt or RPM packages.

I agree completely - I held back on releasing even the original
PyKDE alpha because I wanted to avoid that. Part of the solution is
simply that I need to test builds on the various distributions - I
haven't noticed any Red Hat problems on this release and I'm sure
that's partly because I finally tested it against RH8. My RH9 and
Mdk 9.1 CDs just arrived from Cheapbytes, so testing against
Mandrake is in the queue. Unfortunately so is a lot of other stuff.

Even RPMs become a problem because the Qt/KDE release cycle is much
shorter than the distribution release cycle, so there's no way to
guarantee that the RPM will install with Qt/KDE versions the user
has installed. Building an RPM for every possible KDE and Qt version
for each distribution isn't very attractive. Plus you'd want to
support at least one or two previous distribution versions too - it
quickly becomes a nightmare. That's one of the reasons I wanted to
get away from the previous system of distributing cpp files instead
of sip files.
 
>> > 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).

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). 

>> The problem is that in some cases, PyKDE will build against
>> later versions (eg PyKDE-3.3.2 will build against everything
>> through sip 3.5 - it just lacks up-to-date KDE stuff) and in
>> other cases it won't (as PyKDE-3.5 won't work with sip 3.6). 

>> I'm going to see if I can handle this somehow so it doesn't
>> occur again. The simplest solution is to provide snapshot
>> releases like Phil does - at the moment I don't find that
>> feasible for PyKDE, but down the road it should be. Otherwise,
>> I need to do some work on PyKDE's build.py and also on the
>> PyKDE sip files.

>> If Phil releases in about 2 weeks (as he indicated in his reply
>> to you) PyKDE-3.6 should be ready shortly after and the problem
>> (for now) will disappear again. Still needs to be addressed
>> though.
 
> 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.
 
> 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. 

Any suggestions on improving this are welcome.

Jim