[Python.NET] path question: clr.so being picky about paths

[Hamilton Link]

Sure enough, under ubuntu (though I'm about to switch to fedora) I only 
need clr.so and Python.Runtime.dll.  So, obviously I have some more 
digging to do on how this all works.  But how is clr.so broken 
precisely?  It appears to work...

h

Christian Heimes wrote:
> Link, Hamilton wrote:
>   
>> - clr.so bootstraps mono (under Windows the OS knows how to dlload a .net assembly already) to enable .net assembly extensions and I assumed perhaps recklessly that it laterals to clr.pyd
>>     
>
> The code in src/monoclr is compiled to a shared library (.so on most 
> Unices and .dyload on Mac OS X) and a standalone Python executable. The 
> library is a Python extension which initializes Mono, loads the 
> Python.Runtime assembly and initializes the rest of PythonDotNET. 
> Finally the clr module is replaced by the clr module from PythonDotNET.
>
> However the code is currently broken. svn blame points to r98 jfrayne. :)
>
>   
>> - clr.pyd loads Python.Runtime.dll
>>     
>
> clr.pyd is a Windows and .NET only Python extension that loads the runtime.
>
> The clr.so/pyd/dyload module is only required when you want to embed 
> .NET code into CPython. For the other way around it's not required.
>
>   
>> - Python.Runtime.dll, regardless of platform, turns around and uses P/Invoke to connect into the libpython2.5.so/dll, and then you're all set
>>     
>
> Yeah. The Python.Runtime assembly also provides the clr module you can 
> see inside Python and the import hook to import namespaces from .NET 
> assemblies.
>
> Christian
>
> _________________________________________________
> Python.NET mailing list - PythonDotNet at python.org
> http://mail.python.org/mailman/listinfo/pythondotnet
>
>
>