Developing modules with ‘pkgutil’

[Ben Finney]

Peter Otten <__peter__ at 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