I actually started implementing the zipimport updates to support res:// urls, I haven't run into the same issue you have, I get the call to zipimporter with the res:// just fine. Where specifically were you running into issues with this?
slide On Mon, Apr 2, 2012 at 1:20 PM, Keith Rome <r...@wintellect.com> wrote: > Following up on this topic from a few weeks ago…. > > > > I did not file an issue on it, because it isn’t directly a part of the > python spec, so it’s more “something I would like to see” and less > “something isn’t working right”. > > > > Anyhow, I have been doing some tinkering. I feel like I am right at the > goal line, and just need a tiny bit of help to cross over it. > > > > The zipimport module is an implementation of “PEP 273: Import Modules from > Zip Archives”. My first tinkerings were with modifying the zipimport class > and ZimImportModule class to facilitate using a URI path as in my suggestion > in the previous email. I ran into a brick wall with this however, because > PythonContext.InitializeModule() still makes calls to both System.IO.Path > directly as well as the GetFullPath() method of the current PAL. Both of > those things prevent me from being able to use anything but a path value > that is valid on the current file system (i.e., I can’t use a > “<protocol>://<address>/<path><resource>” scheme). > > > > In reading the details of PEP 273, I also learned about “PEP 302: New Import > Hooks” (http://www.python.org/dev/peps/pep-0302/). This PEP looks to be > exactly what I want, because it is totally transparent to sys.path, and > therefore has no need for any of the path canonicalization workarounds that > I was running into with a PEP 273 solution. PEP 302 appears to already be > implemented in IronPython… at least sys.meta_path is there, and the > IronPython.Runtime.Importer class attempts to make use of it. > > > > So I fully implemented a zip resource based meta_path importer by following > the example of zipimport but adapting it for how meta_path is intended to > work. It appears to work fine for simple imports. But there is a major > problem I have encountered. The meta_path functionality does not appear to > be re-entrant, and I have not yet been able to figure out why. > > > > Implementing a meta_path importer is fairly simple (easier than a path hook > importer like zipimport). I just have to implement find_module() and > load_module() and append my importer to sys.meta_path. These work as > expected. But the final step of the importer protocol dictates that “If the > module is a Python module (as opposed to a built-in module or a dynamically > loaded extension), it should execute the module's code in the module's > global name space (module.__dict__).” This is easy enough, and works exactly > like in zipimport. PythonContext.CompileModule() produces an executable > ScriptCode object, and I simply Run() it using the module’s Scope. > > > > This then proceeds to execute the module initialization code, which > invariably does some imports of its own. As a test case, I use the following > script: “from multiprocessing import process”. The multiprocessing module > attempts to “import os” among other things. I would expect this to invoke > find_module(‘os’) and subsequently load_module(‘os’) on my meta_path > importer. But it does not. For whatever reason, when initializing a module, > any internal attempts to resolve further imports seem to be ignoring > meta_path importers. These imports fail because they should have been > serviced by my meta_path importer, which was not invoked. > > > > 1. Has anyone implemented a meta_path importer in IronPython that > could maybe shed some light on this? > > 2. Is this working as intended? (doesn’t seem to be) > > 3. Is the PEP 302 support perhaps incomplete? > > 4. Am I maybe missing a step somewhere? > > > > I have followed the advice in PEP 302. In addition to everything zipimport > does, I am also setting __file__ to “<resource>”, and setting __path__ to an > empty List. I also ensure that the module is added to sys.modules before > executing the initialization code, and I check sys.modules at the very start > of my load_module() method to prevent double-loading. Although it would seem > that none of those things would have any bearing on this particular issue. > > > > > > Keith Rome > > Senior Consultant and Architect > > MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS > > Wintellect | 770.617.4016 | kr...@wintellect.com > > www.wintellect.com > > > > From: Slide [mailto:slide.o....@gmail.com] > Sent: Monday, March 12, 2012 10:03 AM > To: Keith Rome > Cc: ironpython-users@python.org > Subject: Re: [Ironpython-users] IronPython 2.7.2 Released > > > > This is a great idea, this functionality does not currently exist, could you > please file a new issue at http://ironpython.codeplex.com? > > > > Thanks, > > > > slide > > On Sun, Mar 11, 2012 at 11:23 PM, Keith Rome <r...@wintellect.com> wrote: > > Thanks for the great work! > > Regarding the new zipimport functionality - is it possible to specify an > embedded resource name for the path to the zip? For example, if I wanted to > distribute a library by just packaging it up within an assembly? Or is it > necessary to write the resource out to a file on disk first? > > Example: > Instead of: sys.path.insert(0, '/path/lib.zip') > Something like: sys.path.insert(0, 'resource:path.lib.zip') > > The primary reason behind wanting to deliver via embedded resource is to > prevent tinkering/tampering by end users. But there are additional reasons > such as simpler deployment under Silverlight and not having to deal with > versioning of extra "satellite" external resources when using our scripting > runtime environment in multiple projects. All of those issues go away when > we can package everything directly within the assembly(s). > > I am currently using a custom PlatformAdaptationLayer to supply the file > contents at runtime and msbuild wildcard inclusion of the libraries and all > subfolders to embed them as resources (something that msbuild tolerates, but > Visual Studio does not). It would be much cleaner to just use zipimport, as > well as much easier to maintain (and the distributed assembly would also be > much smaller due to zip compression). > > > Keith Rome > Senior Consultant and Architect > MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS > Wintellect | 770.617.4016 | kr...@wintellect.com > www.wintellect.com > > > > > _______________________________________________ > Ironpython-users mailing list > Ironpython-users@python.org > http://mail.python.org/mailman/listinfo/ironpython-users > -- Website: http://earl-of-code.com _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org http://mail.python.org/mailman/listinfo/ironpython-users
