import other modules from extensions...

gnome-shell-extension-file-import.txt

10:37 <@owen> pfox__: don't think there's any way at the moment
10:39 < pfox__> owen: wow. bummer.. i guess i can have a "build" script to cat the files together or something into an extension.js
10:39 < pfox__> still sucks.
10:39 <@owen> pfox__: or you can improve the situation!
10:39 <@owen> (though I think that might require gjs hacking.)
10:40 < pfox__> owen: yeah.. trying to think of where to start
10:40 < pfox__> i guess commjs require() would be a good way to do it
10:40 < pfox__> i have no idea where it should be impl'd, though
10:40 < pfox__> commonjs, even
10:40 <@owen> pfox__:  doesn't seem to make sense to me - we have a way of doing imports with 'imports' having a *different* way in addiiton would just be weird
10:41 <@owen> pfox__: from Python experience, I don't think we want imports.foo to automatically start in the cwd of the current JS file
10:42 < pfox__> owen: i think id like a string require, defaulting to cwd
10:42 < pfox__> imports.require('foo.js') or whatever
10:42 < pfox__> '../bar.js', etc
10:43 < pfox__> which is pretty pervasive in other places (client-side script includesr, node.js, etc)
10:44 < pfox__> because, while i understand that gnome-shell strives for continuity and whatnot.. there's an existing body of (pretty good) patterns and practices for this. commonjs is one initiative on that front, for example.
10:44 < pfox__> and goes all the way down the rabbit hole with io, etc
10:44 < pfox__> i don't know how much of that would be germaine to gnome-shell
10:44 <@danw> pfox__: we have imports (look at the existing code), but i don't think the extension mechanism adds your extension directory to the search list for them
10:44 <@owen> Note that we have a custom extension importer already
10:45 <@owen> pfox__: Note that we have IO - GIO
10:45 < pfox__> i see
10:45 < pfox__> ok. ill take a look at the importer code. maybe its just a matter of adding the CWD to the search list and going from there. in any case.. as "serious" extension development picks up
10:45 < pfox__> this is something you'll be hearing a lot about from users, i imagine
10:46 < pfox__> thanks for hints
10:46 <@owen> pfox__: I think yo ucan do something like imports.ui.extensionSystem.extensions.<myExtensionId>.module
10:47 <@owen> pfox__: that's obviously pretty cumbersome
10:48 < pfox__> owen: cool.. yeah, i need to check this all out later.. not at my gnome-shell setup, atm
10:48 <@owen> pfox__: it's probably possible to make imports._ be the parent importer of this module
10:49 <@owen> pfox__: though that would likely require some spidermonkey magic to traverse the call stack to figure out where it's being referred to
10:50 <@owen> pfox__: having a separate global scope object which is the parent importer woudl be close to trivial, but pretty ugly to write const MySiblingModule = parentImports.mySiblingModule
10:50 <@owen> or slightly ugly anyways
10:51 < halfline> fwiw, when i first did the gnome-session bits as an extension i had
10:51 < halfline> const Extension = imports.ui.extensionSystem.extensions['[email protected]'];
10:51 < halfline> at the top
10:51 < halfline> and then stuff like const Inhibitor = Extension.inhibitor;
10:52 -!- tanuva [[email protected]] has joined #gnome-shell
10:52 -!- mclasen_ [[email protected]] has quit [Remote closed the connection]
10:52 <@owen> halfline: not horrrible boilerplate, though a little magic
10:53 < halfline> yea it's a little unfortunate that you have to encode the name of the extension inside the extension there when you don't have to do it anywhere else inside the file
10:53 <@owen> halfline: and in every file of the extension
10:54 < halfline> well in my case the other files didn't need to refer to each other
10:54 < halfline> so i only had it in the one file