[pygtk] The Great Master Plan for Python Bindings
jnelson-pygtk at securepipe.com
Wed Oct 13 21:11:18 WST 2004
On Wed, 13 Oct 2004, Murray Cumming wrote:
> > On Tue, Oct 12, 2004 at 09:28:37PM +0100, Gustavo J. A. M. Carneiro
> >> First of all, we have the problem of gnome-python being proposed for
> >> inclusion in the gnome bindings. Since it contains bindings for
> libraries that do not belong to the GNOME Developer Platform, they should
> be split out of gnome-python. I am personally in favour of this approach.
> > I am as well if this means something like the pygtk-extras package we
> had discussed earlier this year. I don't think it's worth the hassle of
> > splitting everything up -- makes it hard for us, makes it hard for the
> end-users who just want to pick up an extra package and go.
> End "users" don't pick gnome-python packages - they pick applications and
> sane distros do the rest for them.
> End "developers who use pygtk" don't use the source tarballs - they use
> the distro packages, which are usually split up completely even if the
> tarball isn't.
> For people who actually work on pygtk, there's jhbuild.
> > Is there a
> > good argument *for* splitting everything up?
> I can think of
> 1. It will be awkward to move something like pygnomeprint from pygtk-extra
> to gnome-python when (if) libgnomeprint becomes part of the GNOME
> 2. Distros must split them up completely, so doing it in the tarball makes
> different distros do that more consistently.
> 3. You would be able to release fixes for the gnome-vfs bindings, for
> instance, even if the bonobo bindings, for instance, are temporarily
> 4. Distros would be able to ship fixes for the gnome-vfs bindings, for
> instance, even if you have released, for instance, broken bonobo bindings.
> 5. It will be easier to share maintenance - in particular, different
> people can decide when different parts of gnome-python make new releases.
> The whole thing is a lot of code for one person to maintain.
I couldn't have said it better. I'm a firm believer in atomicity, and
that includes packages. Sometimes it's difficult, expensive, or
impossible to test an upgraded package which contains several new
versions of individual components. This is just one of the reasons why I
was so happy to see pygnome and pygtk become seperate entities. In the
case that the gnome-print becomes an official part of gnome, then it's a
simple matter of altering the dependencies to include pygnome-print (or
whatever). It's also much easier to make fixes to discrete packages.
"Never try to write to ROM - it wastes your time and annoys the ROM."
Jon Nelson <jnelson-pygtk at securepipe.com>
C and Python Code Gardener
More information about the pygtk