IronPython has the following scheme for loading Python modules:
-
IronPython looks for all the PythonModuleAttribute custom
attributes inside any assembly registered with IronPython using
“clr.AddReference(assemblyName)” which is similar to “require” in Ruby.
The assembly-level attributes point to all the Python modules available
inside the assembly. For eg, “[assembly: PythonModuleAttribute(“nt”,
typeof(IronPython.Modules.PythonNT))]” indicates that the “PythonNT” C#
type implements the “nt” Python module. A single assembly can contain
multiple Python modules.
-
On startup, IronPython registers IronPython.Modules.dll
automatically. Hence, all Python modules from the dll become accessible.
-
Python loads site.py on startup. The site.py that ships with
IronPython looks inside a specific folder and registers all assemblies
in that folder. So a user can drop an assembly in this folder, and all
the Python modules in the assembly will become accessible. I believe Seo
uses this to good measure in FePy to make his own set of Python modules
available to users.
-
Accessible modules are put on a stand-by list. They get
activated only if the user does “import someModule” which is similar to
“require” in Ruby. Until then, the user is not exposed to the fact that
the modules are accessible.
Could a similar scheme work for IronRuby? All the small IronRuby
libraries owned by external committers could live in an assembly like
IronRuby.Libraries.Staging.dll, and this could be placed in some
well-known folder relative to IronRuby.dll. Size should not be much of
an issue in Silverlight as you would expect that the IronRuby runtime
and libraries would be cached on the user’s machine most of the time. If
it does become an issue, we can later break up
IronRuby.Libraries.Staging.dll into smaller pieces. Once the DLR gets
more stable, IronRuby.Libraries.Staging.dll can be merged into
IronRuby.Libraries.dll.
Thanks,
Shri
Want to work on IronPython, IronRuby,
F#http://blogs.msdn.com/ironpython/archive/2008/02/25/ironpython-ironruby-and-f-openings-in-dev-test-and-pm.aspx?
Visit IronPython Blog | Microsoft Learn
From: [email protected]
[mailto:[email protected]] On Behalf Of Ryan R.
Sent: Thursday, May 01, 2008 6:49 AM
To: [email protected]
Subject: Re: [Ironruby-core] Opening up our tree to external committers
On Thu, May 1, 2008 at 2:37 AM, Jimmy S.
<[email protected]mailto:[email protected]>
wrote:
Splitting into different DLLs complicate things for Silverlight.
On the desktop you can have the assembly loading be dynamic with a
foo.rb wrapper for a library. However, Silverlight (today) requires the
DLL would have to be downloaded to the client first before loading. In
other words, the AppManifest.xaml (and the XAP, but that’s optional)
would have to know about ALL the IronRuby Library DLLs you “could” want
to use. We automate the generation of this file and XAP, so that tool
(Chiron) would need to know this. While this isn’t a direct problem, it
does make the # of assemblies you need to include with your app go from
2 to n. Splitting could potentially save download size, but figuring out
which DLLs to include is hard (see below).
Are there other options for how to get DLLs onto a client machine?
To get this option out of the way, we can’t bake this logic (download an
assembly when you require it) into our Silverlight integration, or even
push the responsibility on the libraries themselves. Downloading in SL
requires asynchronous requests, and we can’t pause user code to do this
(aka. Continuations). We could technically implement it by hacking on
XmlHttpRequest directly to get synchronous support, but ugh. If network
connection gets flakey your browser hangs … not very pleasant.
Do we introduce a config.rb to Silverlight that lets you define the
closure of all the assemblies you’ll need? This file gets loaded first,
it triggers the downloads the necessary assemblies, and then load the
real program?
Again, the AppManifest solution will work, but it’s not very
dynamic-language-esc, and becomes more apparent if we split the
libraries out. I’m just brainstorming for better solutions to this.
Ideas?
~Jimmy
Wouldn’t this, then, lend itself toward a solution towards that proposed
by /M:D? I don’t know multi-file assemblies that well, but it seems the
best solution in that, iirc, only the .netmodules needed are loaded as
they are called, but they’re already linked by the primary assembly.
This might be more complicated to maintain and cleanly build; I don’t
know. I also don’t quite understand the “not dynamic” comment, but
again, I’m not too familiar with multi-file assemblies.
(Also, apologies for the duplicate in the other thread.)
-R2
