Author has moved up to IronPython 2 beta 2
IronPython is a .NET implementation of Python. It is claimed to run Python code 1.8x faster than CPython, but has a number of architectural differences that make it less than 100% compatible.
This page is intended (at this time) to aid exploration of what changes to the Bazaar codebase would improve IronPython compatibility without compromising CPython compatibility or introducing IronPython specific code.
IronPython support is not (as far as the author knows) any kind of priority for the Bazaar team.
IronPython Differences Relevant to Bazaar
Code that checks sys.platform will not work properly on IPY. Most of the code that checks for Windows quirks tests sys.platform to see if it equals "win32". There are a few other places where it's tested for 'darwin'. The majority of such checks are in the tests, or abstracted in osutils. The tests should probably all be ported to using osutils to determine feature support in the platform (is there a reason they are not?). Where platform checks are performed outside osutils in the main codebase, they could be abstracted as capability/behaviour check functions in osutils. Capability/behaviour checks in osutils may require changes to reliably express the underlying behaviour of the host system which IronPython is running in.
sys.platform == 'cli' # not 'win32' as you might expect ; it's also 'cli', not 'posix' on IronPython/Mono/Linux
"nt" in sys.builtin_module_names
appears to be an equivalent check on both CPython and IronPython.
-- Can you please say what value of os.name on Windows and Linux in IronPython? --AlexanderBelchenko -- IronPython does not seem to implement "os", so the CPython implementation must be imported ; os.name is "nt" and "posix" respectively.
- Garbage Collected, not reference counted
- Author was unable to find any bzr code that cares about this
- Does not support C API
- No caching of *.py output files ; no *.pyc, no *.pyo.
- This increases load time a lot as IPY has to generate assemblies for each module from scratch.
- This might still be ok for something like a memory-resident shell extension, an IDE plugin, or a GUI client.
Attempts to get things working
Bug in IronPython prevents import of BZR but you can patch around it IronPython Bug filed this bug is fixed in IPY beta 2
- Continued by trying to run testsuite
- Does not implement module subprocess.
- CPython subprocess does not work
- Detects "cli" as posix
- If you work around this, IPY does not implement msvcrt ; as a CPython builtin, this is where.
Probably needs subprocess implementation in IronPython
- CPython subprocess does not work
- Found a partial implementation of the subprocess module
- Passes "2/3" of the CPython tests
* This avoids the attempt to load the fcntl module in CPython subprocess * Next error :
- This appears to be
3# ./ipy testbzr.py bzr: warning: unknown encoding . Continuing with ascii encoding. Traceback (most recent call last): File "testbzr.py", line 4, in testbzr.py File "f:\src\bzr\bzr.iron\bzrlib\tests\__init__.py", line 51, in f:\src\bzr\bzr.iron\bzrlib\tests\__init__.py File "f:\src\bzr\bzr.iron\bzrlib\memorytree.py", line 25, in f:\src\bzr\bzr.iron\bzrlib\memorytree.py File "f:\src\bzr\bzr.iron\bzrlib\mutabletree.py", line 37, in f:\src\bzr\bzr.iron\bzrlib\mutabletree.py File "f:\src\bzr\bzr.iron\bzrlib\tree.py", line 25, in f:\src\bzr\bzr.iron\bzrlib\tree.py File "f:\src\bzr\bzr.iron\bzrlib\conflicts.py", line 37, in f:\src\bzr\bzr.iron\bzrlib\conflicts.py File "f:\src\bzr\bzr.iron\bzrlib\option.py", line 31, in f:\src\bzr\bzr.iron\bzrlib\option.py File "f:\src\bzr\bzr.iron\bzrlib\log.py", line 75, in f:\src\bzr\bzr.iron\bzrlib\log.py File "f:\src\bzr\bzr.iron\bzrlib\repository.py", line 447, in f:\src\bzr\bzr.iron\bzrlib\repository.py File "f:\src\bzr\bzr.iron\bzrlib\repository.py", line 867, in Repository File "f:\src\bzr\bzr.iron\bzrlib\decorators.py", line 104, in _pretty_needs_read_lock NameError: name 'True' is not defined
IronPython on Mono
While the primary line of IronPython development is on Windows, in theory it should also run on Mono (and does at least manage a workable console). Since Mono supports Posix features, it would be possible to access features like signals when running Bazaar on IronPython/Mono. This also means you cannot rely on using sys.platform == 'cli' to determine path behaviour, etc.
Bazaar as a Powershell snap-in
Powershell is a shell for Windows which is predominantly about the concept of pipelining .NET objects rather than byte streams. Bazaar as a Powershell snap-in might enable some interesting use cases. Since PoSH is natively a .NET application, IronPython would be the easiest gateway to PoSH.