[pygtk] CVS branches and plans for the future.

James Henstridge james at daa.com.au
Wed Sep 3 17:19:36 WST 2003


On 3/09/2003 9:50 AM, Malcolm Tredinnick wrote:

> Firstly, sincere congratulations on making the 2.0.0 releases. It is
>
>wonderful to see all your hard work over the years pay off so far. :)
>
Thanks!


[stuff about pygtk future]

>Agreed.
>  
>

[stuff about pyorbit]

> Yes and yes.
>
>What do you think about moving the gtksourceview bindings into the main
>module (I'm not sure where exactly in the directory tree)? This is all
>said without having talked to the maintainer about his plans, but I like
>the idea of having a single-source download for this kind of stuff.
>Things like vte are different, since it includes the Python bindings in
>the main module.
>
This is an interesting question.  I really don't want to stick bindings 
for too many libraries into the pygtk tarball.  I think it is a good 
thing that it is fairly low in the dependency stack, since it makes it 
easier for other packages to depend on pygtk for their builds.

Making these sort of things optional dependencies is really a copout 
though.  For people building packages (ie. Linux distros, etc), the 
optional dependencies are essentially hard dependencies if they want all 
features of the package to be built (even if they then split things up 
into multiple binary packages).  If pygtk has an optional dependency on 
libfoo, then other packages that depend on pygtk (optional or not) will 
also depend on libfoo.  If these dependencies get too complex, they are 
likely to either (a) not build pygtk's libfoo binding, or parts of other 
packages that depend on pygtk.

Now it might make sense to distribute the GtkSourceView binding with 
gnome-python.  Alternatively, it might make sense to package them with 
GtkSourceView itself (like with VTE).  I don't know.

>>Any comments?
>>    
>>
>My only real request is to continue supporting Python 2.2. I was one of
>the people in favour of requiring 2.2 early on, so this risks sounding
>hypocritical, but the changes between 2.2 and 2.3 are not as large as
>from 2.1 to 2.2 and there will be a lot of installations with no plans
>to upgrade for some time. (OK, this is partly selfish: I've just got
>people at work beginning to use some apps in PyGTK and we have no
>upgrade plans in the near future for a large number of pragmatic
>reasons.)
>
>(In case that sounds wrong in email, I am not sure what your plans are
>-- this is just a pre-emptive $0.02 strike. :-) )
>
There is one big improvement in Python 2.3 that would be worth making 
use of: the new PyGILState APIs, which could significantly reduce the 
complexity of PyGTK's thread support (and get it to play nicer with 
other threading aware Python extensions):
    http://www.python.org/peps/pep-0311.html

It is definitely worth experimenting here.  Whether we go for 
conditional compilation, or disabling threading for Python 2.2, or not 
make use of it at all is not clear.

For a non-threaded build, I see no reason to require 2.3 though.


James.

-- 
Email: james at daa.com.au
WWW:   http://www.daa.com.au/~james/





More information about the pygtk mailing list