GNOME Bugzilla – Bug 308328
should probably support python distutils setup.py
Last modified: 2006-07-25 16:59:43 UTC
I'd prefer it if all useful python programs were autogenned, but since they
aren't, it would be nice if there was a cvssetuppy module. [Alternative name
suggestions acceptable :) I'm looking at implementing at least basic support for
this right now, thought I'd file a bug as a placeholder.
[My main motivation for this is ldtp, FWIW.]
Created attachment 48025 [details] [review]
an ugly first cut at this.
Attached is a (poor) cvssetuppy module. It works, at least for the ldtp case-
the only thing I've found to test it on so far. It is hacked out of the mozilla
* this is sort of hackish- it inherits from cvsmodule, which inherits from
autogen module, so I end up overriding most autogen module functions. I could
reimplement at the same level as the autogen module (in utils.py?) if that
* I think I need to redefine the build states (since there is no 'configure'
state here) but I'm not quite sure how to do that yet, though admittedly I
haven't looked hard. For the meantime I've just introduced a couple dummy
functions that pass you on to the next state, just in case. [ATM it seems to
ignore -a and -c, though I think those should work. Not sure what is wrong
* parse_cvssetuppymodule feels particularly ugly; it is totally copy/pasted and
I've not cut anything out for fear of breaking it, but I'm pretty sure 90% of
it is useless. I'll try to clean that out tonight or tomorrow.
* you can't pass any build/install options ATM. Should be easy enough to add, I
guess, if anyone cares.
Created attachment 48027 [details] [review]
patch against 2.12 moduleset
This adds ldtp stuff to the gnome-2.12 moduleset, allowing for testing of the
Comment on attachment 48025 [details] [review]
an ugly first cut at this.
Marking this a patch for reporting/searching purposes, even though it is really
an additional file and not a patch.
This probably indicates that the existing module type system is not sufficient.
At the moment, I have the following class heirarchy:
However, if we add distutils support, ideally we should be able to combine it
with any of CVS, Subversion, Arch or any other revision control system we
support (in the case of Python distutils, we'd want to support "tarball" too).
So it seems that inheritance isn't the best way to combine the repository type
with the build rules. I'll need to think about this a bit more ...
Note: don't take the above statement to mean that I won't accept your patch. If
you get the LDTP stuff working before I get time to refactor the build
infrastructure, it would make sense to check in your module type even if it
isn't implemented in the best way.
hehe. I wouldn't necessarily take my patch... this is not exactly my strongest
work ;) As pointed out in bug 308352, there are a lot of other blockers on the
LDTP stuff ATM, so we'll see how that goes.
I put up some of my thoughts about refactoring the module type code here:
With the introduction of iso-codes in Gnome-2.12 this subject "should probably
support python setup.py" becomes even more probable. jhbuild bootstrap upgrades
Python to version 2.4.1 but it does not install PyXML and that is required to
Adding support for setup.py-style packages is certainly a goal. It won't help
with the iso-codes build, however.
At the moment iso-codes explicitly uses /usr/bin/python, so the system Python
needs to have PyXML installed. To help make building the package easier, I
submitted a patch that should make the module buildable with or without PyXML:
Once the current refactoring is done, it should be very easy to add distutils module support such that it functions with every supported version control system.
Added support for distutils modules. Should work with the following syntax:
<branch repo="bar" module="baz"/>
How does one get distutils modules obtained from tarballs instead of some repository to work? This is currently needed for dbus-python (well, for those of us creating tarball modulesets for gnome 2.15.x point releases based off jhbuild anyway), and would also solve bug 311563. It seems that it should be something easy but I appear to have missed it.
I caught James on irc and got the necessary hints from him there. An example for how to do this for a tarball version of dbus-python is:
<repository type="tarball" name="dbus/dbus-python"
size="137613" md5sum="ee893bc87b784a8c2285f5041b5e7033" />