Re: Proposing module: PyGTK

[Andrew Sobala <aes gnome org>]

On Tue, 2004-11-02 at 20:27 +1100, Jeff Waugh wrote:
> <quote who="Mark McLoughlin">
> 
> >   1) The expectations we want to set to modules in the Desktop release -
> >      i.e. we want those modules to feel free to depend on pygtk, but not
> >      any of the other members of the bindings release.
> 
> >   2) The expectations we want to set to external developers - i.e. do we
> >      want the python binding to be "just another GNOME binding" or do
> >      we want it to enjoy a higher status above the other bindings?
> 
> > 	I think it all hinges on how we feel about (2) - if the python binding
> > should be an officially way to write against the GNOME platform and
> > "more blessed" than the other bindings, then I think it belongs in the
> > Platform release set. If not, it should stay in the Bindings release
> > set.
> > 
> > 	(1) doesn't matter all that much - if, from (2), it should stay in the
> > Bindings release set, then we can fudge it just like you say ... i.e.
> > that Desktop modules can depend on pygtk but not the other bindings or
> > that pygtk be listed in the Desktop release set too.
> 
> Hrm, see, I think that (2) doesn't matter all that much, because we already
> make our commitment to external developers clear -> the Bindings suite is
> meant to be stable enough that they can rely on it for their applications.
> 
> (1) seems to be where things are unclear. Saying that "Desktop modules can
> use pygtk, which is in the Bindings suite" seems pretty wishy-washy to me,
> compared to the clarity of the Platform and Desktop suites.

We already have a set of rules for modules that want to go into
platform/desktop. These include: use gnome CVS, by i18nised, be
a11yised, be b00gised, and so on. (The CVS one has exceptions, I know,
but the point still stands.) Until now, one of the unspoken rules was
"don't depend on a binding" :)

We can just say "Desktop modules can be in python now, as well as C." We
can do that without having 2 copies of PyGTK in different release sets -
this is a social problem, not an engineering one, and we don't need to
solve it in a way a computer would understand. Just in a way that people
understand. And if you're writing an application for the Desktop, you're
going to have to find out our requirements anyway; adding an extra one
isn't a big issue.

However, putting PyGTK in the platform does imply more blessedness (is
that a word?) to external developers - external developers *who don't
read our mailing lists* and aren't part of the community. This is an
assurance we don't want to give; the blessedness of PyGTK relates to us
trying to keep the languages we use in the Desktop as low as possible,
rather than it being necessarily "better" than the other bindings.

-- 
Andrew