Peter Otten <__pete...@web.de> writes: > Weird idea. Try putting the following in your __init__.py files: > > import pkgutil > __path__ = pkgutil.extend_path(__path__, __name__) > __path__.reverse() > import __init__ > globals().update(vars(__init__)) > __path__.reverse()
That's rather astounding. It doesn't *quite* work, but here's what did work: ===== # docutils/__init__.py # Python package for in-development docutils packages. import pkgutil # Ensure we can also reach modules in the system package __path__ = pkgutil.extend_path(__path__, __name__) # Make this directory come last when importing from this package __path__.reverse() # Make this package gain all the attributes of the system package _path_prev = __path__ import __init__ globals().update(vars(__init__)) __path__ = _path_prev del _path_prev # Make this directory come first when importing from this package __path__.reverse() ===== Plus the same thing in ‘docutils/writers/__init__.py’. Pretty ugly. I hope namespace packages can come along and save us from this. > If that doesn't work add > > import docutils > docutils.__path__.insert(0, path_to_modified_version) > > to your main script. Repeat for every subpackage. No, modifying the program is exactly what I'm trying to avoid; that file, unlike these development-only shims, will actually be installed on the end-user's system. The point of the exercise is to set up the development working tree so that it presents the in-development module transparently to the program, and the program remains untainted by these ugly hacks :-) But, since the above re-worked package module does the job, I'm able to continue (though appalled at the hackiness required). Thank you! -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\ Brain, but isn't a cucumber that small called a gherkin?” | _o__) —_Pinky and The Brain_ | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
