Package that imports with name of dependent package

2006-05-13 Thread 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

Re: Package that imports with name of dependent package

2006-05-13 Thread Maric Michaud
Le Samedi 13 Mai 2006 16:05, David Pratt a écrit : I'd appreciate hearing of what I can do in an __init__ file or what other strategy could make this work. Many thanks. you should leave the original package intact and patch it with new mehod and moddule; for example (A is the original package):

Re: Package that imports with name of dependent package

2006-05-13 Thread 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.

Re: Package that imports with name of dependent package

2006-05-13 Thread 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__ =

Re: Package that imports with name of dependent package

2006-05-13 Thread 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

Re: Package that imports with name of dependent package

2006-05-13 Thread David Pratt
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