Problem with ihooks: not working as expected in Py25 with eggs?
Hello,
I'm using the following recipe (which I shall publish one day in the cookbook):
============== nobarepyc.py ========================= import ihooks import os
class _NoBarePycHooks(ihooks.Hooks): def load_compiled(self, name, filename, *args, **kwargs): sourcefn = os.path.splitext(filename)[0] + ".py" if not os.path.isfile(sourcefn): raise ImportError('forbidden import of bare .pyc file: %r' % filename) return ihooks.Hooks.load_compiled(name, filename, *args, **kwargs)
ihooks.ModuleImporter(ihooks.ModuleLoader(_NoBarePycHooks())).install() ============== nobarepyc.py =========================
This is useful when managing Python source trees with CVS/SVN: after a file is renamed or moved, you don't want imports to silently import the previously generated .pyc file. By importing this module in debug builds, you install an import hook that makes so a "bare" .pyc file (with no .py file next to it) is never imported.
Now, this file does not seem to work with packages shipped as .egg files, at least in Python 2.5. Specifically, I get an import error with setuptools itself:
from misc import nobarepyc import pkg_resources
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\Python25\lib\ihooks.py", line 404, in import_module q, tail = self.find_head_package(parent, str(name)) File "C:\Python25\lib\ihooks.py", line 447, in find_head_package raise ImportError, "No module named " + qname ImportError: No module named pkg_resources
*IF* I can read this traceback correctly, this has nothing to do with my own hook: it's ihooks itself which appears to be broken with .egg files. Is that correct? Does .egg files break ihooks? What is the correct way of writing this sort of import hooks with setuptools / .egg files?
Thanks
At 05:11 PM 10/23/2006 +0200, Giovanni Bajo wrote:
from misc import nobarepyc import pkg_resources
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\Python25\lib\ihooks.py", line 404, in import_module q, tail = self.find_head_package(parent, str(name)) File "C:\Python25\lib\ihooks.py", line 447, in find_head_package raise ImportError, "No module named " + qname ImportError: No module named pkg_resources
*IF* I can read this traceback correctly, this has nothing to do with my own hook: it's ihooks itself which appears to be broken with .egg files. Is that correct? Does .egg files break ihooks?
If I'm reading it correctly, ihooks expects modules to be files, period. So it's not going to work with any zipfile, let alone eggs. The workaround would be to configure easy_install to --always-unzip when installing. See the manual for details.
(Note that ihooks predates PEP 302 and therefore does not support it. ihooks in fact *replaces* the built-in import mechanism entirely, so it's not likely to work correctly with any other PEP 302-based features besides eggs.)
Phillip J. Eby wrote:
If I'm reading it correctly, ihooks expects modules to be files, period. So it's not going to work with any zipfile, let alone eggs. The workaround would be to configure easy_install to --always-unzip when installing. See the manual for details.
Yes that's a workaround but I'd rather avoid it if possible.
(Note that ihooks predates PEP 302 and therefore does not support it. ihooks in fact *replaces* the built-in import mechanism entirely, so it's not likely to work correctly with any other PEP 302-based features besides eggs.)
I see. If you were to write the module I showed you, using a PEP-302 compatible system, what would you use? Is it possible to achieve the same thing in such few lines, but being PEP-302 compatible?
At 12:25 AM 10/24/2006 +0200, Giovanni Bajo wrote:
Phillip J. Eby wrote:
If I'm reading it correctly, ihooks expects modules to be files, period. So it's not going to work with any zipfile, let alone eggs. The workaround would be to configure easy_install to --always-unzip when installing. See the manual for details.
Yes that's a workaround but I'd rather avoid it if possible.
(Note that ihooks predates PEP 302 and therefore does not support it. ihooks in fact *replaces* the built-in import mechanism entirely, so it's not likely to work correctly with any other PEP 302-based features besides eggs.)
I see. If you were to write the module I showed you, using a PEP-302 compatible system, what would you use? Is it possible to achieve the same thing in such few lines, but being PEP-302 compatible?
Not in just a few lines, no. It would take quite a few, I'm afraid. PEP 302 doesn't provide a filesystem abstraction, and isn't likely to grow one soon. Maybe by Python 2.6 or 3.0, depending on how much free time I end up getting in the next couple of years. :)
participants (2)
-
Giovanni Bajo -
Phillip J. Eby