Bazaar on IronPython

[Martin (gzlist)]

In short, see the attached patch for getting bazaar to run on
IronPython. It only passes a subset of the tests, but can do some of
the basics like creating a new repo, adding and diffing, and
committing the changes. This is not intended for merging, many of the
changes are addressing interpreter bugs and differences rather than
problems with the code. However there are a number of issues raised
that might be of interest to bazaar developers.

Having nibbled round the edges of the bzrlib.osutils module, I wanted
a task that would serve as an excuse to look over the platform related
code as a whole. I'd downloaded IronPython some months back and not
had cause to play with it, and seeing that Adrian Wilkins investigated
this a year ago and wrote up some helpful tips, it seemed achievable.
<http://bazaar-vcs.org/IronPython>
<http://ironpython-urls.blogspot.com/2008/03/bazaar-on-ironpython.html>

My basic strategy was to get selftest working then deal with
categories of test failures. I mostly used IronPython 2.0.0 though I
tried the first 2.6 beta towards the end, which threw up a few extra
issues, but may have been a better choice to start as it's less
compiling-the-world slow on every invocation. There's still work to be
done to make bazaar generally usable under IronPython, and fair bit of
low hanging fruit (for instance I left warnings about terminal
encodings untouched as a useful progress indicator).

Some misc observations from the process:

Bazaar has a lot of platform switching code in various different
places. I get a strong impression that anything touching sys.platform
or errno should be migrated to osutils.

Using ref-counted RAII is convenient. To change everything to
finally-close would be too much pain for no actual benefit.

Required modules - I could get away with moving subprocess and bz2 to
lazy import, but too much of the test suite mechanics depended on
zlib. There's an emulation binary created by Jeff Hardy that resolved
that, though it has various problems (noted in the patch near the
workarounds).
<http://jdhardy.blogspot.com/2008/12/solving-zlib-problem-ironpythonzlib.html>
<http://cid-414fa1a9bd174b4b.skydrive.live.com/self.aspx/Public/IronPython.Zlib.zip>

The combination of bazaar trying to pretend that everything is a UTF-8
byte string and IronPython trying to pretend the str type is unicode
is recipe for trouble.  I think bazaar should give here, and sort out
a better set of idioms for working with both binary data and
non-english text - it'll be needed for Python 3 anyway.
<http://www.infoq.com/news/2007/06/IronPython-STR>
<http://www.smallshire.org.uk/sufficientlysmall/2009/06/18/string-compatibility-between-python-implementations/>

IronPython tries in some places to be helpful by stubbing in various
methods and raising NotImplementedError-s from them - but didn't get
the signatures right, so you get some completely different cryptic
exception instead.

This line at the bottom of bzrlib.builtins:
    from bzrlib.foreign import cmd_dpush
pulls in a bunch of extra imports, and makes a difference of about a
tenth of a second and a megabyte of disk read to `bzr rocks` on my
machine. Or twenty four seconds for IronPython 2.0.0...
Likewise, it seems to make inspect_for_copy.py pointless. Is there any
ongoing auditing of perf hacks like the lazy imports and regexps and
this to ensure they remain net wins?

Overall, it was quite impressive how little needed altering, though
the path to discovering those small changes was often winding, even
the root cause was the same as a previously handled issue.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ironpython.bundle
Type: application/octet-stream
Size: 51277 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090627/81fcb380/attachment-0001.obj