[IronPython] pywin32 on Iron Python?
dfugate at microsoft.com
Wed Apr 29 18:55:52 CEST 2009
The technical bar for inclusion of 3rd party tests into our checkin system is pretty simple - the test process needs to emit a non-zero exit code when it fails. When some portion of a test fails under IronPython for whatever reason, we simply disable that portion. For example, we run around 200 CPython 2.6 test_*.py files for every IronPython checkin with roughly a thousand individual test cases in these modules disabled. With this in mind, it likely doesn't matter that most of Django's test suite does not pass => we can disable the broken stuff.
As for inclusion of commit messages in the CodePlex source synchs, we'll look into this. It's a bit challenging as sometimes we work on getting IronPython running against/with the latest unannounced Microsoft technology (e.g., we had IronPython running under Silverlight months before Silverlight was publically announced) and this is often reflected in our checkin comments.
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Vernon Cole
Sent: Wednesday, April 29, 2009 7:34 AM
To: Discussion of IronPython
Subject: Re: [IronPython] pywin32 on Iron Python?
On Tue, Apr 28, 2009 at 5:32 PM, Jeff Hardy <jdhardy at gmail.com> wrote:
> Hi Dave,
> On Tue, Apr 28, 2009 at 10:37 AM, Dave Fugate <dfugate at microsoft.com> wrote:
>> That said, there is something extremely useful the community can do for IronPython that our team simply cannot: get 3rd party Python applications such as Django, pywin32, NumPy, etc running under IronPython. This could mean adapting something like adodbapi.py to utilize IronPython APIs similar to what Vernon Cole did, or re-implementing NumPy's C-based modules in C#. While it's quite difficult (impossible?) for anyone on our team to submit changes supporting IronPython back to other OSS projects, the rest of the IronPython Community happily doesn't have this limitation.
My condolences on having to put up with the lawyers. I have to sleep
with one, but at least she doesn't tell me who I can contribute code
> The problem with this approach is that I don't really want to clutter
> up e.g. Django with workarounds for IP bugs that are actually
> incompatibilities with CPython - they should and will get fixed in IP
> at some point. If it's a legitimate platform difference, or an invalid
> assumption by Django, then it can be fixed there - but I've found very
> few of those relative to bugs in IP itself.
That's true. There is still one outstanding bug in adodbapi on iron
which I hope will eventually be fixed in IPy. (see Work Item # 18222
-- August 2008) The workaround was just too large to use and would
still have left the IPy COM implementation with a bug. When the COM
bug gets fixed that last test failure will go away. There are other
places where "if IronPython:" made sense and was used. (I also
included simple workarounds for bugs like #18223.)
> Also, would it possible for you guys to revisit your commit messages?
> I would at least like to see a note in the CP commit messages when a
> particular CP issue has been fixed.
+ 1. Maybe my bug has already been fixed and I don't know.
>> If anyone wants to contribute in this manner, please just give us a heads up so we can obtain permission to add tests for the 3rd party app(s) to our checkin system. Also, if there's enough interest in this I can setup a wiki page on CodePlex to keep track of whose working on what...
+1 on the wiki page.
> Now this is interesting! Last time I checked, Django's test suite was
> nowhere near passing - would the full test suite have to pass before
> you'd include it?
In other words, how good do we have to get?
> I really appreciate the work you guys are doing here. It can't be easy
> swimming against the tide all the time!
> - Jeff
Users mailing list
Users at lists.ironpython.com
More information about the Ironpython-users