WIP: Rewrite using sublime_plugin.load_module.

[Thom1729]

Sublime 3189 provides a new sublime_plugin.load_module() function. This allows us to load a module without using Sublime's reloading code, which may let us substantially simplify the reloading code. This PR is a first draft of what such a simplification may look like.

The current reloading algorithm goes like this:

0. Resolve dependencies, find modules to reload.
1. Unload plugins (using sublime_plugin.unload_module).
2. Remove modules from sys.modules.
3. Reload plugins (using sublime_plugin.reload_plugin). This should reload the modules.

Step 2 is not desirable by itself, but it's necessary because sublime_plugin.reload_plugin both reloads the given module and registers its contents with Sublime, and the reloading part works differently depending on whether the given module is in sys.modules. If it is, then reload_plugin will call unload_module, which we already called in step 1. Therefore, it has proved necessary to manually remove items from sys.modules to invoke the second case in reload_plugin. That case, in turn, calls importlib.import_module directly rather than using __import__, which means that we have to temporarily add a new finder to sys.meta_path to intercept the top-level plugin imports and actually reload modules.

This PR uses the new sublime_plugin.load_module, which only registers the given module's contents with Sublime and does not attempt to unload the plugin contents or reload the module. (In essence, load_module is the counterpart to unload_module, whereas reload_plugin is more like unload_plugin.) This allows the following algorithm:

0. Resolve dependencies, find modules to reload.
1. Unload plugins (using sublime_plugin.unload_module).
2. Reload modules.
3. Load plugins (using sublime_plugin.load_module).

Because load_module won't trigger module reloads, we can do it ourselves. The implementation in the PR does this by patching __import__ in a similar way to importing_fromlist_aggresively (and subsuming the latter). This ensures that modules are reloaded in the correct order without needing to modify either sys.modules or sys.meta_path.

The advantages of this approach are:

• It's less code.
• It patches fewer things -- still __import__, but no longer sys.modules or sys.meta_path.
• It's less reliant on the internals of sublime_plugin.
• All modules remain in place during the reload, which should reduce the likelihood of errors when other code calls a module that's being reloaded.
• Modules are never removed, so we don't need to put them back (such as in case of an error).

Disadvantages may include:

• It's a substantial change.
• It may behave differently with some kinds of dynamic module loading.
• We'll have to provide a fallback implementation of load_module for older versions of Sublime. (This is messy, but it won't break on us because old versions won't change.)

This PR isn't ready; I need to do more testing and write the fallback code. The approach should be pretty stable, though, so I'd appreciate any comments or feedback.

[randy3k]

Awesome job. You mentioned that the current reloader code does not work in some edge cases, would you provide some insights?

Fallback may not be necessary, we could put a requirement of build 3189 on Package Control and show an error message to users who clone the repo directly but with build <3189.

[FichteFoll]

You could also just ship an older build for older versions through package control's release channels (like for st2).

[randy3k]

You could also just ship an older build for older versions through package control's release channels (like for st2).

I think it is what I 've said. Perhaps my english has broken.... nevermind

[FichteFoll]

No, you just didn't mention to keep the old version and ship it for older at builds.

[randy3k]

oh, you are right. I was thinking it is the same process....

[randy3k]

Let's target it for ST4! 😄

[randy3k]

@Thom1729 If you don't have anything to add, I am going to merge this.

PS: I have already pined the last tag for pre-3189 builds.