On 6/25/07, chris vigelius <chris.vigelius@gmx.net> wrote:

Hi Chris,

I'm currently trying to make a patch which adresses the long-standing
symlink problem on Unix platforms, as I am using Ubuntu Feisty and they
have almost every library symlinked...


REF.getFileAbsolutePath() canonicalizes the path passed to it, so
resolveModule is called with "/usr/share/python-support/...". But
resolveModule() internally matches the passed file against pythonpath,
and since this is different from the real path (because of the resolved
symlink), it is dropped.

My question is now, why this matching is done in the first place? To
determine the package name, one could just walk up the directories and
look for __init.py__, that would be not only faster but also remove the
symlink problem. Are there any special reasons why the canonical path of
a module must be compared against pythonpath?

The current implementation is the way it is because it can resolve module names even if the file does not exist. E.g.: When a file is removed, the code-completion builder will have to remove the AST cache for that file -- but when that happens, the file does not actually exist anymore... you can see that the signature it has is:

public String resolveModule(String fullPath, final boolean requireFileToExist)

So, if the file does not exist, it might be difficult to resolve it...

Still, I thought it didn't actually resolve symlinks, but you're right about getCanonicalPath, so, I think this can be worked on -- initially making it resolve the modules in the changePythonPath, when we know that the files exist -- fixing it in the builder (for projects) may be a different story (at: ProjectModulesManagerBuild.rebuildModule)... anyway, 1st things 1st...

The solutions available (I think) would be:
- Creating a new resolveModule that would work on existing files
- Resolving the module when we're looking for the files in the pythonpath (currently in listFilesForCompletion, it uses pythonPathHelper.getModulesBelow to get a list of files and then resolves it, but maybe this could be changed to resolve the File and the actual module name at the same time).

I think that the second approach would probably be better... would you be willing to take a look at it?