Package that imports with name of dependent package

[David Pratt]

Hi. I have code that currently depends on a particular package of a
framework. I have decided I want to create my own package because I have
made many changes and it is getting too difficult to maintain each time
I retrieve an updated version of the framework from svn.

The problem is, that there are all sorts of imports to the dependent
package throughout my code and I just want to replace this module with
something that will provide a reference to my own package without
changing the original imports. So it just needs to point to the new
package so that the original imports in my code will continue to work.

For example, here is a package structure.

dependentpackag e
|
+---- __init__.py
+---- somemodule.py
+---- somefolder
|
+---- __init__.py
+---- somesubmodule.p y
+---- someotherfolder
etc ....

I simply want the dependentpackag e to point to the new package leaving
no more than an init file or whatever would have to be minimally
required to make this work

dependentpackag e
|
+---- __init__.py

mypackage
|
+---- __init__.py
+---- somemodule.py
+---- somefolder
|
+---- __init__.py
+---- somesubmodule.p y
+---- someotherfolder
etc ....

I my code I still need to have this work:

from dependentpackag e.somemodule import something

- but I want the package to be getting the code from the new module.

I'd appreciate hearing of what I can do in an __init__ file or what
other strategy could make this work. Many thanks.

Regards,
David

[Peter Otten]

David Pratt wrote:

Hi. I have code that currently depends on a particular package of a
framework. I have decided I want to create my own package because I have
made many changes and it is getting too difficult to maintain each time
I retrieve an updated version of the framework from svn.

The problem is, that there are all sorts of imports to the dependent
package throughout my code and I just want to replace this module with
something that will provide a reference to my own package without
changing the original imports. So it just needs to point to the new
package so that the original imports in my code will continue to work.

For example, here is a package structure.

dependentpackag e
|
+---- __init__.py
+---- somemodule.py
+---- somefolder
|
+---- __init__.py
+---- somesubmodule.p y
+---- someotherfolder
etc ....

I simply want the dependentpackag e to point to the new package leaving
no more than an init file or whatever would have to be minimally
required to make this work

dependentpackag e
|
+---- __init__.py

mypackage
|
+---- __init__.py
+---- somemodule.py
+---- somefolder
|
+---- __init__.py
+---- somesubmodule.p y
+---- someotherfolder
etc ....

I my code I still need to have this work:

from dependentpackag e.somemodule import something

- but I want the package to be getting the code from the new module.

I'd appreciate hearing of what I can do in an __init__ file or what
other strategy could make this work. Many thanks.

I think fixing the imports is the better long-term approach. But putting

from pkgutil import extend_path
import mypackage
__path__ = extend_path(myp ackage.__path__ , __name__)

into dependentpackag e/__init__.py might work.

Peter

[Peter Otten]

Peter Otten wrote:

I'd appreciate hearing of what I can do in an __init__ file or what
other strategy could make this work. Many thanks.

I think fixing the imports is the better long-term approach. But putting

from pkgutil import extend_path
import mypackage
__path__ = extend_path(myp ackage.__path__ , __name__)

into dependentpackag e/__init__.py might work.

One big caveat: If you are mixing both

import mypackage.somem odule

and

import dependentpackag e.somemodule

in the same application, mypackage.somem odule and
dependentpackag e.somemodule are *not* the same module instance. This may
have surprising effects when global variables in somemodule.py are
updated...

Peter

[David Pratt]

Hi Peter. I'd like to fix the imports, but this would impact the
portability of portions of the code that currently work with the
existing package from the framework.

This solution does the trick and allows me to create the package I want
using a good amount of new material. I don't have to worry about adding
to the original package each time a release comes out. I'll only have to
monitor code changes for an impact on my classes, subclasses, etc. Still
a pain, but a smaller one :-) Many thanks.

Regards
David
Peter Otten wrote:

from pkgutil import extend_path
import mypackage
__path__ = extend_path(myp ackage.__path__ , __name__)

into dependentpackag e/__init__.py might work.

Peter

[David Pratt]

Hi Peter. Thank you for this warning. I'll document this in the code. I
plan on importing only from dependentpackag e for portability. Also, much
in the framework relies upon it. This approach is primarily for
maintenance purposes and would also allow me to package the modified
dependentpackag e (with just the __init__.py ) along with mypackage if I
plan to distribute it. It allows it to be a drop in replacement.

I am hoping with packaging utilities, I can easily remove the
dependentpackag e if it is encountered in site-packages to replace it
with my own.

Regards,
David
Peter Otten wrote:

Peter Otten wrote:

I'd appreciate hearing of what I can do in an __init__ file or what
other strategy could make this work. Many thanks.

I think fixing the imports is the better long-term approach. But putting

from pkgutil import extend_path
import mypackage
__path__ = extend_path(myp ackage.__path__ , __name__)

into dependentpackag e/__init__.py might work.

One big caveat: If you are mixing both

import mypackage.somem odule

and

import dependentpackag e.somemodule

in the same application, mypackage.somem odule and
dependentpackag e.somemodule are *not* the same module instance. This may
have surprising effects when global variables in somemodule.py are
updated...

Peter