After installing pydbgr 1.4.1 and import_relative 0.1.0 on a Linux system with Python 2.6.4 using

python setup.py install

(i.e., not the eggs provided on the respective project websites), I observed the following error when I ran /usr/bin/pydbgr:

$ pydbgr Traceback (most recent call last): File "/usr/bin/pydbgr", line 9, in <module> load_entry_point('pydbgr==0.1.4', 'console_scripts', 'pydbgr')() File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 299, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 2229, in load_entry_point return ep.load() File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 1948, in load entry = import(self.module_name, globals(),globals(), ['name']) File "/usr/lib/python2.6/site-packages/pydbgr/cli.py", line 30, in <module> Mapi = import_relative('api', top_name=package) File "/usr/lib/python2.6/site-packages/import_relative.py", line 136, in import_relative description) File "/usr/lib/python2.6/site-packages/pydbgr/api.py", line 38, in <module> Mdebugger = import_relative('debugger', top_name='pydbgr') File "/usr/lib/python2.6/site-packages/import_relative.py", line 136, in import_relative description) File "/usr/lib/python2.6/site-packages/pydbgr/debugger.py", line 39, in <module> Mcore = import_relative('core', '.lib', 'pydbgr') File "/usr/lib/python2.6/site-packages/import_relative.py", line 136, in import_relative description) File "/usr/lib/python2.6/site-packages/pydbgr/lib/core.py", line 36, in <module> Mcmdproc = import_relative('cmdproc', '..processor', 'pydbgr') File "/usr/lib/python2.6/site-packages/import_relative.py", line 136, in import_relative description) File "/usr/lib/python2.6/site-packages/pydbgr/processor/cmdproc.py", line 22, in <module> import_relative('lib', '..', 'pydbgr') File "/usr/lib/python2.6/site-packages/import_relative.py", line 116, in import_relative if not mod or not mod.file.startswith(top_file_prefix): AttributeError: 'module' object has no attribute 'file'

I meant pydbgr 0.1.4.

I wonder if module.file started in Python 2.6.5 ?

The problem still occurs with Python 2.6.5.

I can't reproduce this so I have to rely on you to get/give information.

If you add print type(mod)

at import_relative.py", line 116, what type does it show before you get an error. For me I always have either:

or

And the 'module' type always has __file_the object dictionary.

Comment deleted

It prints . The module in question is pydbgr.lib; if I try to import that manually in an interactive python session, I can confirm that it doesn't possess a file attribute. Further investigation reveals that the init.py files in the pydbgr source package are not installed when I install pydbgr via python setup.py install. Might this be due the fact that the various Python packages in pydbgr are declared as namespace packages in the setuptools configuration in setup.py?

Thanks for doing those investigations. I think we are closer to understanding, but I still can't reproduce the problem with just the information given so far. So I think what I need is more detailed output. Not only what you typed but what was typed back. By way of comparison, here is what I get when I run python ./setup.py install and then run pydbgr:

python ./setup.py install

running install running bdist_egg running egg_info writing requirements to pydbgr.egg-info/requires.txt writing pydbgr.egg-info/PKG-INFO writing namespace_packages to pydbgr.egg-info/namespace_packages.txt writing top-level names to pydbgr.egg-info/top_level.txt writing dependency_links to pydbgr.egg-info/dependency_links.txt writing entry points to pydbgr.egg-info/entry_points.txt writing manifest file 'pydbgr.egg-info/SOURCES.txt' installing library code to build/bdist.linux-i686/egg running install_lib running build_py creating build/bdist.linux-i686/egg creating build/bdist.linux-i686/egg/pydbgr creating build/bdist.linux-i686/egg/pydbgr/lib copying build/lib.linux-i686-2.6/pydbgr/lib/sighandler.py -> build/bdist.linux-i686/egg/pydbgr/lib copying build/lib.linux-i686-2.6/pydbgr/lib/disassemble.py -> build/bdist.linux-i686/egg/pydbgr/lib copying build/lib.linux-i686-2.6/pydbgr/lib/breakpoint.py -> build/bdist.linux-i686/egg/pydbgr/lib copying build/lib.linux-i686-2.6/pydbgr/lib/stack.py -> build/bdist.linux-i686/egg/pydbgr/lib copying build/lib.linux-i686-2.6/pydbgr/lib/thread.py -> build/bdist.linux-i686/egg/pydbgr/lib copying build/lib.linux-i686-2.6/pydbgr/lib/core.py -> build/bdist.linux-i686/egg/pydbgr/lib copying build/lib.linux-i686-2.6/pydbgr/lib/print.py -> build/bdist.linux-i686/egg/pydbgr/lib copying build/lib.linux-i686-2.6/pydbgr/lib/bytecode.py -> build/bdist.linux-i686/egg/pydbgr/lib copying build/lib.linux-i686-2.6/pydbgr/lib/file.py -> build/bdist.linux-i686/egg/pydbgr/lib copying build/lib.linux-i686-2.6/pydbgr/lib/display.py -> build/bdist.linux-i686/egg/pydbgr/lib copying build/lib.linux-i686-2.6/pydbgr/lib/init.py -> build/bdist.linux-i686/egg/pydbgr/lib

... Adding pydbgr 0.1.5 to easy-install.pth file Installing pydbgrc script to /usr/local/bin Installing pydbgr script to /usr/local/bin

Installed /usr/local/lib/python2.6/dist-packages/pydbgr-0.1.5-py2.6.egg Processing dependencies for pydbgr==0.1.5 Searching for tracer==0.2.4 Best match: tracer 0.2.4 Processing tracer-0.2.4-py2.6.egg tracer 0.2.4 is already the active version in easy-install.pth

Using /usr/local/lib/python2.6/dist-packages/tracer-0.2.4-py2.6.egg Searching for pyficache==0.1.3 Best match: pyficache 0.1.3 Processing pyficache-0.1.3-py2.6.egg pyficache 0.1.3 is already the active version in easy-install.pth

Using /usr/local/lib/python2.6/dist-packages/pyficache-0.1.3-py2.6.egg Searching for import-relative==0.1.0 Best match: import-relative 0.1.0 Processing import_relative-0.1.0-py2.6.egg import-relative 0.1.0 is already the active version in easy-install.pth

Using /usr/local/lib/python2.6/dist-packages/import_relative-0.1.0-py2.6.egg Searching for columnize==0.3.2 Best match: columnize 0.3.2 Processing columnize-0.3.2-py2.6.egg columnize 0.3.2 is already the active version in easy-install.pth

Using /usr/local/lib/python2.6/dist-packages/columnize-0.3.2-py2.6.egg Searching for coverage==3.3.1 Best match: coverage 3.3.1 Processing coverage-3.3.1-py2.6-linux-i686.egg coverage 3.3.1 is already the active version in easy-install.pth Installing coverage script to /usr/local/bin

Using /usr/local/lib/python2.6/dist-packages/coverage-3.3.1-py2.6-linux-i686.egg Finished processing dependencies for pydbgr==0.1.5

cd ..

pydbgr ipython

(/usr/bin/ipython:24): -> 24 """ (Pydbgr) Leaving

With tracer 0.2.4, import_relative 0.1.0, columnize 0.3.3, pyficache 0.1.4, coverage 3.4, and setuptools 0.6c11 already installed, I obtain the output in the attached log file when I run python setup.py install --root=/tmp/foo from within the pydbgr-0.1.4 source directory. I'm running the installation on a 64-bit Linux system. Notice that the init.py are skipped because they are in namespace packages.

Looking at the setuptools code, it looks like you get this only when using the setup.py --root option (which not shown in your initial bug report) and setuptools version 06c or greater. (The version number which was also missing up until the last comment).

I don't know how to get setuptools to change its behavior. I want it to copy the init.py files and want the namespace packages. A workaround for now is to copy those init.py files back.

I'm also seeing this on Ubuntu 10.04 (Python 2.6), with a pip-installed pydbgr.

i also see this with pydbgr-0.1.5, Python 2.6.6, distribute-0.6.14 instead of setuptools, and the following related Python packages:

columnize-0.3.3 coverage-3.4 import_relative-0.1.0 pyficache-0.1.4 tracer-0.2.5

the projects that i am trying to debug are installed as egg-links via pip -E /path/to/my/env install -e .. all of the projects' dependencies are pulled in by pip automatically. in other words, i never install by calling python setup.py directly.

didn't setuptools and distribute stop installing init modules for namespace packages for a reason? if so, then reverting this behavior seems like a misguided approach. instead, perhaps import_relative should be patched to not rely on __file__, at least for namespace packages.

regarding the suggested workaround: copying the init.py files is somewhat painstaking if the corresponding packages were installed directly from PyPI (e.g. via pip). in this case, my error is triggered on pydbgr.lib, but i installed pydbgr from PyPI. can anyone think of another workaround?

Without a doubt, the culprit here is a very faulty import_relative implementation that I wrote.

The right approach I think is to rewrite this using Brett Cannon's importers module. http://packages.python.org/importers/#module-importers

My understanding from watching Brett's PyCon 2010 talk that importlib works currently only on Python 3.1 and someone needs to port it to 2.x. He suggests it is a straightforward port.

Any takers?

I would have done this already but situation but I don't use Python right now very much. pydbgr has been fine for my needs.

It is sad to me that an equivalent to Ruby's require_relative doesn't exist in Python. Yes, I know about the relative imports in Python 2.x, but they apparently don't play nice with modules that can be run as standalone files, which is the case with virtually all of the pydbgr files.

Finally I'll mention that the way Sridhar Ratnakumar at ActiveState.com handled this was to patch their builder to delete *.egg-info/ directories from the package root (they are not needed for building anyway). See http://code.activestate.com/pypm/pydbgr/0.1.4.

Has this ever been fixed? I'm seeing the same error message on OSX 10.6.8 with Python 2.7.2 and fresh installs (from today, using PyPi) of pydbgr and import_relative.

Thanks.

i too saw this recently. i concluded that pydbgr is unmaintained, since it's pretty much impossible to use it now. and pydb is no longer available in PyPI. so i'm using the standard pdb instead. see http://docs.python.org/library/pdb.html.

Could the author explain what would be the cons, besides loosing compatibility with earlier versions of Python, of replacing all calls to import_relative() with standard relative imports (e.g., import ..pydbg.debugger as mydbg). Does import_relative() do anything that the built-in import doesn't do?

Thanks!

for a discussion of the differences between import relative, see https://groups.google.com/group/comp.lang.python/browse_thread/thread/a5c08a6456d1bcd2/43f7f1dffb4b5495?lnk=gst

based on that Google Groups discussion and on the website of pyimport-relative (the project that provides import_relative) [1], it appears that import_relative is actually subsumed by import. further, since import supports a from list, it appears that it is actually a superset of the functionality in import_relative.

[1] http://code.google.com/p/pyimport-relative/

however, comment #12 seems to indicate (though not directly) that import_relative supports "relative" imports in such a way that "relative" is defined according to a file system hierarchy rather than a package hierarchy. this is different from Python's relative imports. in many cases, a package-relative import spec (e.g. ..module) remains the same when defined as a file-relative import spec (if the imported module is located at ../module.(py|pyc|pyo)). and when each directory in the tree contains an init module, the converse is also true. but since there are , so the two are not equivalent.

i'm curious to know the authors' intentions in using import_relative. there are numerous references to it in pydbgr's source, so it's not immediately clear.

i suspect that one or both of the following is true:

• import_relative is used for importing pydbgr's own modules.

• import_relative is used for importing the modules of a project on which pydbgr is invoked, relying on some module layout specified by pydbgr.

• import_relative is used for importing ordinary modules and scripts of a project on which pydbgr is invoked.

in the first case, the fix is simple for the pydbgr developers--add init modules to declare all of pydbgr's packages. in the second case, pydbgr's users can't reasonably expect their modules to work (let alone for pydbgr to work with them) if they are trying to use relative imports outside a package hierarchy. in the third case, the modules and scripts can only perform relative imports on whatever is in their own package hierarchies, so either import or importlib.import_module (depending on the use case) will work already.

i wrote a rather flexible importing module for one of my projects recently. it supports importing based on various combinations of module path, file path, and directory tree path. it works with relative module paths and with file paths to Python bytecode and shared library files. it builds off import, importlib.import_module, and imp.load_(source|compiled|dynamic). it may not be complete or bulletproof, but it's a solid start. i'd be happy to share it or insights from it.

If you look at the bottom of many of the files in pydbgr, you'll find little demo or test code. Pre 3k versions of "Dive into Python" describe this kind of use.

I require...

1. The ability to run each file and get demo/test code after if name == 'main'.

2. The ability to run large swaths of the program, submodules, or the entire program without having to "install" it.

The following is not a requirement but a strong aesthetic concern:

There should be a clear distinction between internal linking, and external "import" linking. While it is fine for separate packages (e.g. columnize, or linecache) to use the external "import" mechanism, for internal linking -- that is linking between the various internal files and modules -- I want to refer to the files via a relative path mechanism. Think of the difference between #include "../foo.h" versus #include in C/C++. The former #include does not go through a search path mechanism while the latter does. Also see Ruby 1.9's "require_relative".

If you have a solution that meets all the desiderata above, take the pydbgr code or a small self-contained part of it, like the I/O system, and modify it so it works with your solution. Then attach a patch. Thanks.

One final note. Comment 17 refers to pydbgr developers in the plural. Although I'd love that to be the case, it has never been the case. The best way to see things through though is participate more actively.

Release 0.1.6 I believe addresses these problems.