Python bindings

[Malcolm Tredinnick]

I just landed the first part of the python bindings. I still need to
finish wrapping about 50 functions by hand (anything involving varargs,
GLists and the like requires hand wrapping), but the basics are there.

I have not turned them on in the build yet, since they are not really
useful in their current state. However, the configure script does check
for the relevant stuff already (it's harmless that they are not used).
If you are really desperate to experiment (or help), just add 'python'
to the SUBDIRS variable in libmrproject/Makefile.am and then run
autogen.sh again.

Richard, Mikael: there is an implicit dependency on PyGTK for building
this stuff. I will set it up so that things will quietly fail (just not
build the bindings) if PyGTK is not installed, but do you think it is
too onerous to require this to make the bindings build work? The reason
for the requirement is that PyGTK installs the pygtk-codegen script for
generating most of the function wrappers.

An alternative to this dependency is that I can check in the generated
file (mrproject.c) and update it from time to time, but that seems
inelegant.

Any advice on this issue appreciated.

Cheers,
Malcolm

[Richard Hult]

Post by Malcolm Tredinnick
I just landed the first part of the python bindings. I still need to
finish wrapping about 50 functions by hand (anything involving varargs,
GLists and the like requires hand wrapping), but the basics are there.

Great, thanks!

Post by Malcolm Tredinnick
Richard, Mikael: there is an implicit dependency on PyGTK for building
this stuff. I will set it up so that things will quietly fail (just not
build the bindings) if PyGTK is not installed, but do you think it is
too onerous to require this to make the bindings build work? The reason
for the requirement is that PyGTK installs the pygtk-codegen script for
generating most of the function wrappers.

As long as the bindings build can be disabled, I'm all for having pygtk
as a requirement.

Richard

[Mikael Hallendal]

Post by Richard Hult

Post by Malcolm Tredinnick
I just landed the first part of the python bindings. I still need to
finish wrapping about 50 functions by hand (anything involving varargs,
GLists and the like requires hand wrapping), but the basics are there.

Great!

Post by Richard Hult

Post by Malcolm Tredinnick
Richard, Mikael: there is an implicit dependency on PyGTK for building
this stuff. I will set it up so that things will quietly fail (just not
build the bindings) if PyGTK is not installed, but do you think it is
too onerous to require this to make the bindings build work? The reason
for the requirement is that PyGTK installs the pygtk-codegen script for
generating most of the function wrappers.

As long as the bindings build can be disabled, I'm all for having pygtk
as a requirement.

Hmm .. if it would be possible to build the bindings without pygtk that
would be the best. But if it's just not doable or too much work I guess
we can live with depending on pygtk in this case.

Having a pygtk dependency for python bindings for libmrproject is pretty
bad, since that involves an extra dependency on. Gtk+, ATK, Pango, X.

For example someone wanting to write a python-cgi script that uses a
mrproject file in the back for something would have to install X and
friends.

Or is it just a build dependency?

Regards,
Mikael Hallendal

[Malcolm Tredinnick]

[...]

Post by Mikael Hallendal

Post by Richard Hult

Post by Malcolm Tredinnick
Richard, Mikael: there is an implicit dependency on PyGTK for building
this stuff. I will set it up so that things will quietly fail (just not
build the bindings) if PyGTK is not installed, but do you think it is
too onerous to require this to make the bindings build work? The reason
for the requirement is that PyGTK installs the pygtk-codegen script for
generating most of the function wrappers.

As long as the bindings build can be disabled, I'm all for having pygtk
as a requirement.

Hmm .. if it would be possible to build the bindings without pygtk that
would be the best. But if it's just not doable or too much work I guess
we can live with depending on pygtk in this case.
Having a pygtk dependency for python bindings for libmrproject is pretty
bad, since that involves an extra dependency on. Gtk+, ATK, Pango, X.
For example someone wanting to write a python-cgi script that uses a
mrproject file in the back for something would have to install X and
friends.

Yeah, all good points.

Post by Mikael Hallendal
Or is it just a build dependency?

It is just a build dependency. PyGTK has a pygtk-codegen script that
takes the mrproject-*.defs files (which can be used for _any_ language
binding -- they are a Scheme like description of the functions and
arguments, etc), combines them with the mrproject.overrides file (which
contains the hand-written wrappers for functions that require them and
so is Python specific) and creates a mrproject.c file of automatically
generated code.

The advantage of this route is that if a systematic bug is discovered in
the code generating stuff, it can be fixed for almost everything in
codegen and that filters through in the next build.

I sympathise with the list of added requirements (although until you
listed them, I had not consciously realised how numerous they were).
Thinking about this some more, I might set things up so that you need
PyGTK to build from CVS only. Then the generated mrproject.c file can be
included in the dist tarball and _if_ somebody building from the tarball
has pygtk-codegen installed, we will conditionally rebuild mrproject.c
at build time. That seems a reasonable balance between checking in
generated sources and requiring something hard to make the build work.

Any obvious problems with this that anybody can see?

Regards,
Malcolm

[Richard Hult]

Post by Malcolm Tredinnick

Post by Mikael Hallendal
Or is it just a build dependency?

It is just a build dependency. PyGTK has a pygtk-codegen script that
takes the mrproject-*.defs files (which can be used for _any_ language
binding -- they are a Scheme like description of the functions and
arguments, etc), combines them with the mrproject.overrides file (which
contains the hand-written wrappers for functions that require them and
so is Python specific) and creates a mrproject.c file of automatically
generated code.

I guess it's also a run-time dependency? Or does pygtk do dynamic
loading of gtk in some way? If gtk, pango, etc, are required during
run-time, then we might as well have it as tarball build-time
requirement too.

In the long run, it would be nice to be able to provide bindings that
don't have this kind of requirements though, for scenarios like the one
Mikael talked about.

Richard

[Malcolm Tredinnick]

Post by Richard Hult

Post by Malcolm Tredinnick

Post by Mikael Hallendal
Or is it just a build dependency?

It is just a build dependency. PyGTK has a pygtk-codegen script that
takes the mrproject-*.defs files (which can be used for _any_ language
binding -- they are a Scheme like description of the functions and
arguments, etc), combines them with the mrproject.overrides file (which
contains the hand-written wrappers for functions that require them and
so is Python specific) and creates a mrproject.c file of automatically
generated code.

I guess it's also a run-time dependency? Or does pygtk do dynamic
loading of gtk in some way? If gtk, pango, etc, are required during
run-time, then we might as well have it as tarball build-time
requirement too.

OK, I am apparently not explaining this very well. Let me try again,
beginning with the binary requirements and working backwards to CVS.

(1) Once everything is built, the python bindings will depend on
libmrproject and whatever libmrproject depends upon (GLib, libxml2,
libgsf). Nothing else. No run-time dependency on GTK or anything like
that.

(2) In order to build the Python bindings, we need the file
python/mrproject.c which contains wrappers for most of the functions,
objects and types in the libmrproject public header files. The remaining
functions (those not wrapped by mrproject.c for technical reasons), are
wrapped by hand and are checked into CVS.

(3) In order to generate mrproject.c, we need to use the codegen.py
script at some point. This script is installed as part of PyGTK. The
source for it is in the gnome-python/pygtk/codegen/ directory in GNOME
CVS. The codegen stuff has no dependency on gtk or anything. It is
simply a bunch of utility scripts for automatically generating code.
They are slightly more specialised than things like SWIG, since the code
knows about GTK widgets and GObject structures and the like, so it can
do a better job with less -- that is why I am using these scripts,
rather than some other code generating tool.

So, it is not beyond the realms of possibility that James Henstridge
could ship the codegen stuff as a separate package. However, it is
currently shipped in PyGTK. The dependency there is simply to get the
tools to generate the code to build the bindings. It is just an
unfortunate packaging decision, in retrospect (to be fair, almost all
the python bindings in GNOME depend in some way on GTK, so it's not an
unreasonable requirement). That is why my current thinking is to ship
the python/mrproject.c file in the distributed tarball and only
regenerate it at build time if the tools are available. I would be
reluctant to check it into CVS, though, so PyGTK (or at least the
codegen portion) will still be required for that.

I might also talk with JamesH about packaging that stuff separately (or
at least checking in a self-contained configure and build system to CVS
so that we can jut make a codegen module in CVSROOT/modules and rely on
that for people who want it).

Post by Richard Hult
In the long run, it would be nice to be able to provide bindings that
don't have this kind of requirements though, for scenarios like the one
Mikael talked about.

I totally agree. In fact, one of the scenarios Mikael mentioned (a cgi
script that produces something from a mrproject file) is exactly why I
started on these bindings a couple of weeks ago.

I have a slightly longer-term plan of wanting to make it possible to
write plug-ins for mrproject in Python, which _will_ require PyGTK and
friends at runtime. But at that point, it will not be an unreasonable
requirement, since if you are writing plugins in Python, you will want
to display widgets at some point, so you need the infrastructure to do
that. However, that is a way down the track yet.

If this is still not clear, please let me know and I will try again
(although I should be able to finish it up over the weekend and you will
be able to see what I am talking about).

Apologies for all the confusion,
Malcolm

[Richard Hult]

Thanks for the explanation, I see it clearly now ;)

Post by Malcolm Tredinnick
That is why my current thinking is to ship
the python/mrproject.c file in the distributed tarball and only
regenerate it at build time if the tools are available. I would be
reluctant to check it into CVS, though, so PyGTK (or at least the
codegen portion) will still be required for that.

We have no problem with that. If you are building from CVS, I think not
having pygtk is your smallest problem ;)

Post by Malcolm Tredinnick
If this is still not clear, please let me know and I will try again
(although I should be able to finish it up over the weekend and you will
be able to see what I am talking about).

Crystal clear, sounds good!

Thanks,
Richard

[Mikael Hallendal]

Post by Malcolm Tredinnick
OK, I am apparently not explaining this very well. Let me try again,
beginning with the binary requirements and working backwards to CVS.

Sorry for being a retard but just to make things clear. Once we have our
bindings in a python module there are no requirements on the G* python
modules?

Post by Malcolm Tredinnick
I have a slightly longer-term plan of wanting to make it possible to
write plug-ins for mrproject in Python, which _will_ require PyGTK and
friends at runtime. But at that point, it will not be an unreasonable
requirement, since if you are writing plugins in Python, you will want
to display widgets at some point, so you need the infrastructure to do
that. However, that is a way down the track yet.

Yeah, that would be really great (and easily achivable once we have our
bindings in place).

Regards,
Mikael Hallendal

[Malcolm Tredinnick]

Post by Mikael Hallendal

Post by Malcolm Tredinnick
OK, I am apparently not explaining this very well. Let me try again,
beginning with the binary requirements and working backwards to CVS.

Sorry for being a retard but just to make things clear. Once we have our
bindings in a python module there are no requirements on the G* python
modules?

That is correct.

Malcolm

[Richard Hult]

Post by Mikael Hallendal
Sorry for being a retard but just to make things clear. Once we have our

Post by Mikael Hallendal
bindings in a python module there are no requirements on the G* python
modules?

That is correct.

So, just so there is no misunderstanding, feel free to commit what you
have.

Mikael and I will go through and wrap what can't be done automatically
some time this week, if you don't beat us to it.

Thanks,
Richard