resolving module name conflicts.

[Gelonida N]

On 11/11/2011 10:31 PM, Emile van Sebille wrote:
> On 11/11/2011 12:27 PM Gelonida N said...
>> Is there any way to tell pytz to import it's own tests package and tell
>> the rest of the code to import the other?
>>
>> Python version is 2.6.5
>>
>>
>> Thanks in advance for any suggestion.
> 
> Start with
> http://docs.python.org/whatsnew/2.5.html#pep-328-absolute-and-relative-imports
> 
Thanks Emile / Thanks Eric


The from __future__ import absolute_import is already used in most files
of this project but only used for importing some other modules.
All the 'tests' modules are still imported with absolute imports.

'tests' is also a top level module of the existing project and being
imported from top level scripts (scripts in the python path directory)

Relative imports don't work on top level scripts as it would raise

> ValueError: Attempted relative import in non-pack

This is a legacy project where many tools assume a certain directory
structure and where I'm kind of hesitant to move files into differnt
directories.

What's probably the most painless fix would be
- force only certain (older?) versions of pytz (which don't expose
	this issue) to be installed.
- rename tests into something else. However this will affect
	loads of files. and I had to check whether there are no
	shell scripts or custom executables, which depend on 'tests'
	being called 'tests'

Pytz is only imported by one module, so I wondered if there were any
tricks to 'change sys.path' prior to importing pytz and to make sure,
that the projects 'tests' package and pytz's 'tests' package could co-exist.

What I wondered is whether there was a way to fix the issue without
having to 'touch' all the 100+ import statements spread over the project.

In the long term I suggest, that the project's code will be changed
such that it will no more conflict with pytz's tests package.
(either rename the package, transform it to a sub package, ... ???),