Repository navigation
Two modules with identical names create a conflict #443
Description
Activity
Promoting, there are user-reported issues on this. Jake Bailey (@jakebailey) can add links.
#1360 is the concrete example with more comments about this. Doing a depth sort as I almost did in #1289 "helps" but disallows valid import names. I'd think we need to have the following:
The import resolver doesn't do the "carving" thing anymore, and instead allows multiple names for the same module. Since we have
PythonModule.Name, if we have a "canonical name" for a module, a wrapper could exist to show that "this module has this name in this context" while passing through the rest.We most probably need this for persistence in some form so we can tell which module the type is from correctly.
For the fix, we need to define how module should be chosen if we have several modules matching the same name. python itself iterates through the
sys.path, where executing directory is the first one.I think there are 2 cases
- inside the product while it is running. Module name + path hash will do, I think. However, that is machine setup specific.
- persistence: name + version + file size + timestamp hash might work.
Doing it by path order is important, yeah. I'd imagine that since this ordering impacts what a module sees in its imports, the "unique ID" may need to involve that as well (i.e. if I install
qt, then whatpandascontains is different due to that addition, rather than being fixed).My other thought was that we could still have a unique name in the dependency resolver, but expose them as the requested name through some sort of shim (i.e. if they have
src.something.else, and through some method we determine that it can be imported viasomething.else, it could still have the same unique ID, but be presented assomething.elsein that new context). I'm not sure what that'd take; we use the module name as the "defining feature" all over the place.Nameis inherited fromIPythonType. Right now we havePythonVariableModule(not the right name, maybe you can suggest a better one), which is created for every referenced module in the scope of the referencing module. So on this level, we can have context-based names. I'll try to separateIPythonModulefromIDocument. If that works, there will be no need for the document in RDT to have a name.dbbranch introducesQualifiedNameto theIPythonType. For module it is justName. Perhaps it can be used as unique name instead?One name isn't enough anyway, because name of the module depends on the referencing module. For example, for the file structure:
root ├─ src │ ├─ package │ │ └─ b.py │ └─ a.py ├─ package │ └─ b.py ├─ a.py └─ d.pyand
d.py:import a import src.a import package.b import src.package.b
we should import all four modules if
root/srcgoes afterroot, and only two modules (fromsrc) if it is added before. So in the second case,b.pycan be imported as bothpackage.bandsrc.package.b.On the other hand, completions, hover and other analysis-based features operate on top of
PythonVariableModule, which isn't shared between analysis instances.On the side note, we need to remember that module wins over implicit package:
root ├─ src │ └─ a.py └─ a └─ b.pyNo matter what path goes first -
rootorroot/src-from a import bwon't work.When using this extension https://github.com/microsoft/vscode-python-embedded , people create
code.pyas the main file for CircuitPython. There is a name collision withcode.pyin the standard lib.
These two modules will have the same name. As a result, one will be overridden by the other in
ModuleTable.See also
ImportTests.Completions_ImportResolution_OneSearchPathInsideAnother