path question: clr.so being picky about paths
In the readme, it says that "python for .net uses the pythonpath (sys.path) to look for assemblies to load, in addition to the usual application base and the gac. Unfortunately at the moment the assembly I'm trying to load is... clr.pyd. If I run python (ubuntu, mono, rebuilt python 2.5.2 with --enable-shared) from a directory where clr.pyd and Python.Runtime.dll reside, with clr.so in the lib/python2.5/site-packages folder... everything works. I can import clr and System.Drawing and make a System.Drawing.Point instance. If I run python from a directory without these libraries, in particular if I'm in my home folder somewhere and clr.pyd and Python.Runtime.dll are in the lib/python2.5/site-packages folder where I want them... import clr gives me an error trying to load some unspecified module (I suspect clr.pyd). Am I supposed to set some path or other for mono in contravention of the docs? I suspect that either clr.so can't find mono, or mono is being loaded and then can't find clr.pyd. I will continue to fiddle with this, probably Friday, if I don't get a response, but it seems like there's probably a simple answer that I'm overlooking. Setting MONO_PATH to my site-packages folder (the variable was unbound before) didn't fix it. h
I got it working on MacOSX under Mono. I'm pretty sure the clr.pyd is only for Windows. I think you just need the Python.Runtime.dll, the Python.Runtime.dll.config, and the clr.so in the site-packages folder. Joe -----Original Message----- From: pythondotnet-bounces+jfrayne=blizzard.com@python.org [mailto:pythondotnet-bounces+jfrayne=blizzard.com@python.org] On Behalf Of Hamilton Link Sent: Tuesday, December 02, 2008 5:19 PM To: pythondotnet@python.org Subject: [Python.NET] path question: clr.so being picky about paths In the readme, it says that "python for .net uses the pythonpath (sys.path) to look for assemblies to load, in addition to the usual application base and the gac. Unfortunately at the moment the assembly I'm trying to load is... clr.pyd. If I run python (ubuntu, mono, rebuilt python 2.5.2 with --enable-shared) from a directory where clr.pyd and Python.Runtime.dll reside, with clr.so in the lib/python2.5/site-packages folder... everything works. I can import clr and System.Drawing and make a System.Drawing.Point instance. If I run python from a directory without these libraries, in particular if I'm in my home folder somewhere and clr.pyd and Python.Runtime.dll are in the lib/python2.5/site-packages folder where I want them... import clr gives me an error trying to load some unspecified module (I suspect clr.pyd). Am I supposed to set some path or other for mono in contravention of the docs? I suspect that either clr.so can't find mono, or mono is being loaded and then can't find clr.pyd. I will continue to fiddle with this, probably Friday, if I don't get a response, but it seems like there's probably a simple answer that I'm overlooking. Setting MONO_PATH to my site-packages folder (the variable was unbound before) didn't fix it. h _________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
I'll go back and look again, but as far as I could tell from the .il code and the .c code for clr.pyd and clr.so... - 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 - clr.pyd loads Python.Runtime.dll - 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 Maybe a dev can confirm or correct me on this, and elaborate a bit? I can certainly try setting aside clr.pyd and I'll keep studying the code, but I guess I didn't notice if clr.so knew to find Python.Runtime.dll after it set up mono. h ________________________________________ From: Joe Frayne [Jfrayne@blizzard.com] Sent: Tuesday, December 02, 2008 7:08 PM To: Link, Hamilton; pythondotnet@python.org Subject: RE: [Python.NET] path question: clr.so being picky about paths I got it working on MacOSX under Mono. I'm pretty sure the clr.pyd is only for Windows. I think you just need the Python.Runtime.dll, the Python.Runtime.dll.config, and the clr.so in the site-packages folder. Joe -----Original Message----- From: pythondotnet-bounces+jfrayne=blizzard.com@python.org [mailto:pythondotnet-bounces+jfrayne=blizzard.com@python.org] On Behalf Of Hamilton Link Sent: Tuesday, December 02, 2008 5:19 PM To: pythondotnet@python.org Subject: [Python.NET] path question: clr.so being picky about paths In the readme, it says that "python for .net uses the pythonpath (sys.path) to look for assemblies to load, in addition to the usual application base and the gac. Unfortunately at the moment the assembly I'm trying to load is... clr.pyd. If I run python (ubuntu, mono, rebuilt python 2.5.2 with --enable-shared) from a directory where clr.pyd and Python.Runtime.dll reside, with clr.so in the lib/python2.5/site-packages folder... everything works. I can import clr and System.Drawing and make a System.Drawing.Point instance. If I run python from a directory without these libraries, in particular if I'm in my home folder somewhere and clr.pyd and Python.Runtime.dll are in the lib/python2.5/site-packages folder where I want them... import clr gives me an error trying to load some unspecified module (I suspect clr.pyd). Am I supposed to set some path or other for mono in contravention of the docs? I suspect that either clr.so can't find mono, or mono is being loaded and then can't find clr.pyd. I will continue to fiddle with this, probably Friday, if I don't get a response, but it seems like there's probably a simple answer that I'm overlooking. Setting MONO_PATH to my site-packages folder (the variable was unbound before) didn't fix it. h _________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
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
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@python.org http://mail.python.org/mailman/listinfo/pythondotnet
Hamilton Link wrote:
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...
There is an error inside the Makefile for clr.so. It can't be build anymore because it's using a wrong argument when linking the object file. Christian
participants (4)
-
Christian Heimes -
Hamilton Link -
Joe Frayne -
Link, Hamilton