By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
426,115 Members | 919 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 426,115 IT Pros & Developers. It's quick & easy.

Package that imports with name of dependent package

P: n/a
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.

dependentpackage
|
+---- __init__.py
+---- somemodule.py
+---- somefolder
|
+---- __init__.py
+---- somesubmodule.py
+---- someotherfolder
etc ....

I simply want the dependentpackage 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

dependentpackage
|
+---- __init__.py

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

I my code I still need to have this work:

from dependentpackage.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

May 13 '06 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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.

dependentpackage
|
+---- __init__.py
+---- somemodule.py
+---- somefolder
|
+---- __init__.py
+---- somesubmodule.py
+---- someotherfolder
etc ....

I simply want the dependentpackage 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

dependentpackage
|
+---- __init__.py

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

I my code I still need to have this work:

from dependentpackage.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(mypackage.__path__, __name__)

into dependentpackage/__init__.py might work.

Peter

May 13 '06 #2

P: n/a
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(mypackage.__path__, __name__)

into dependentpackage/__init__.py might work.


One big caveat: If you are mixing both

import mypackage.somemodule

and

import dependentpackage.somemodule

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

Peter
May 13 '06 #3

P: n/a
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(mypackage.__path__, __name__)

into dependentpackage/__init__.py might work.

Peter

May 13 '06 #4

P: n/a
Hi Peter. Thank you for this warning. I'll document this in the code. I
plan on importing only from dependentpackage 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
dependentpackage (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
dependentpackage 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(mypackage.__path__, __name__)

into dependentpackage/__init__.py might work.


One big caveat: If you are mixing both

import mypackage.somemodule

and

import dependentpackage.somemodule

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

Peter

May 13 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.