[IronPython] Newbie question: can I build .NET assemblies from Python code?

[J. Merrill]

At 03:36 AM 1/15/2006, Devin Ganger wrote
>J. Merrill wrote:
>
>> Actually, I just took a look and the RADIUS library is _not_ 
>> C-based.  However, it relies on at least one Python standard 
>> library that is not yet implemented in IronPython.  So you're 
>> in the same situation -- the RADIUS library will work not 
>> work with IronPython "as is.
>
>This is the pyrad library, yes? Out of curiosity, which library isn't
>implemented in IronPython yet?

pyrad 0.8.  It uses the standard Python "socket" library, which has not been implemented (yet) for IP.  I haven't looked, but I suspect that on every platform at least some parts of that library are implemented in C (to get at OS-level socket functionality).  It may use other not-implemented standard Python modules as well; I did not look in detail.

>On a theoretical level, if I *did* have all of the libraries I needed
>available, would it be possible to compile a self-contained .NET
>assembly out of the Python code?

Not without a bit of hassle, at this beta stage.  One of the things not fully baked is the "build .Net libraries for use from outside" -- there is no mechanism to compile some .py file into a .Net DLL that can be used trivially by any .Net language.  (Such a DLL would require the IronPython assemblies, of course.)  However, you can jump through hoops involving renaming intended-to-be-temporary assemblies that the console app writes to file.  We are promised much better "from outside IronPython" usage of pre-compiled IP code in the future.

>> It is not difficult to write COM server apps in Python; the
>> Python library that helps you do that (called win32com) is
>> part of the standard Python distribution.
>
>Hmm. That's an approach I hadn't considered.

That's why I mentioned it...but discussion of that approach should be done elsewhere as it would no longer involve IronPython.

>> your C# code should be able to work with it easily, particularly
>> as you'll be able to design the COM side to match what the C#
>> side needs done
>
>I see what you're saying. Check me on this: anyone who wanted to use my
>project would then have to have Python installed, along with the pyrad
>library, along with my Python COM server wrapper for it, yes? That's a
>number of hoops to jump through and I suspect the result would be that
>no one (myself included) uses this particular module (I'm trying to do
>an authentication add-on for a blogging system).

Not necessarily, as CPython has mechanisms that allow you to create what are known as "frozen executables" where all the code needed (an embedded Python interpreter, your Python "main" module, and all Python modules that your code uses) can be glued together into a single .EXE file.  (It's possible that some programs you already have on your Windows machines are written in Python.)  Look here for more info:

http://starship.python.net/crew/atuining/cx_Freeze/README.txt

>Since I have to learn C# in more depth anyway, I guess I'll go with plan
>A and work with some friends to create a native C# RADIUS client
>implementation. In the meantime, though, I'll be keeping my eye on
>IronPython.

Depending on how many C-style structures etc are involved, this could be trivial or annoying experimentation with various "interop" mechanisms.

People who have looked at it say that implementing the socket library for IP (by using the .Net socket libraries) should not be difficult.  Why no one has done it if that's the case, I don't know; maybe someone did just what they needed and didn't share it as it's incomplete.  

You could check to see what parts of the socket library are used by the pyrad client code; if it's a small percentage (as I'd expect, as you're only building a client and not a server) you could build your own socket-subset package using IP's support for calling .Net libraries.

>Thanks for the answers!

Good luck.

>--
>Devin L. Ganger                    Email: deving at 3sharp.com
>3Sharp LLC                         Phone: 425.882.1032 x 109
>15311 NE 90th Street                Cell: 425.239.2575
>Redmond, WA  98052                   Fax: 425.702.8455
>(e)Mail Insecurity: http://blogs.3sharp.com/blog/deving/


J. Merrill / Analytical Software Corp