GNOME Bugzilla – Bug 735541
Import caches modules incorrectly
Last modified: 2016-11-17 07:54:08 UTC
Created attachment 284629 [details] demonstration of the problem It's possible to end up in the situation where you try import a module, but the importer returns a different module that has the same name but a different path. See the attached tarball; unzip it, cd importbug, and run bug.js to see what I mean. Looking at load_module_init() in importer.cpp, it looks like it checks whether the module name is defined as a property on the importer object, and if so, returns the already-imported module of that name. I would suggest caching by the module's path rather than its name.
The issue is that you're trying hack up the search path and then pop from it afterwards to import a private module. I'd say that just like in Python, modules are global singletons and are qualified by their fully imported path. In Python, the solution to this would be to bypass sys.modules by using __import__. I started working on an importer rewrite a little while ago that allowed for that. Overall, I want to move towards newer standards for gjs modules, not swerve away from them.
(In reply to comment #1) > The issue is that you're trying hack up the search path and then pop from it > afterwards to import a private module. I'd say that just like in Python, > modules are global singletons and are qualified by their fully imported path. By fully imported path, do you mean the path to the module on the filesystem? If so, we agree. But right now they are qualified by their module name. > In Python, the solution to this would be to bypass sys.modules by using > __import__. I started working on an importer rewrite a little while ago that > allowed for that. Yes, I'd be interested in a workaround as well. One obvious workaround is to just not give those modules the same name. I do see code in importer.cpp that seems to create a new importer object; how does one trigger that from the GJS side?
Subimporters are created for subdirectories. So, imports.sub.private.ambig would be a separate import from imports.ambig. The issue is the search path stuff.
Closing this, the imports system should keep working the way it does now until it's replaced by ES6 modules; and the workaround is good enough for most people's purposes.