When is the plugin reloading event been spawned?

[BPL]

Mostly of the time plugin reloading is flawless so there isn’t basically much to talk or complain about it. Nevertheless, today I’ve found one particular case where plugin reloading won’t be spawned so I was wondering if that was the expected behaviour or not.

Let’s consider EasyClangComplete plugin. If I edit and save the main source file the plugin is reloaded but if instead I edit and save some of the child files, like this one the reloading process won’t be spawned, is this a bug?

Is there any way to force the plugin reloading without having to switch to the main file and saving to force the reloading?

[Clams]

It is not a bug
I have not tested it but there is a plugin for that: https://packagecontrol.io/packages/Package%20Reloader

[BPL]

Thanks, that one is 4 years old and kinda intrusive, you need to create a .build file on the package you want to reload. I’ve also found this one called AutomaticPackageReload, I’ll give it a shot.

In any case, why ST is not doing this by itself (implemented in the Core) without using any external package? Well, I guess it isn’t that simple scanning the whole bunch of python dependencies of the N possible packages available, even so…

[deathaxe]

ST uses python’s imp.reload() API function to reload a plugin. This function works well for single modules, while it is critical to reload already imported libraries which depend on each other. Which one to load first, which one later? What happens if single modules no longer exist but are still referenced in another. …?

One could argument, that python should automatically reload all imports, if a top-level module is reloaded in the correct order, just as it did the first time. In real life it does not, as it is quite uncommon in a normal use case to keep a top-level script running while an imported module is changed. You close your app, update all modules and restart.

What AutomaticPackageReloader does is to intercept python’s module import process to force all imports and their imports to reload. This uses internal functions of python, which should maybe not be used in normal applications and can’t even handle all situations perfectly. Renamed or deleted modules or global variables still cause trouble and will cause the reload process to fail.

imp.reload() even tends to create new instances of several class objects or global variables, which may cause unpredictable results. This happens for example if one top-level python-file is imported by another one. The imported one may exist twice in pythons namespace in the end.

The only way to solve it is to place imported library-modules into sub directories (sub-packages) as they are not handled by ST. As an developer you can use AutomaticPackageReloader to avoid about 90% of restarts but you have in mind, if something heavily changed, you still need to. But this may not be desirable behavior for the every-day life.

Let’s say, ST handles loading/unloading the main file as it always works. If a package provides more comprehensive functionality, it is responsible to handle its modules itself - as it should know how to.

The other possible answer might be the authors not to have had the complexity of some of today’s packages in mind when the plugin API was built. Have a look into the Default.sublime-package. Most plugins are single small and standalone.