Sublime Forum

How can I reload a plugin in sublime console?

#1

Is there any way allow us reload a plugin in the console?

0 Likes
#2

why not just add the package to your ignored packages, save your preferences, then remove it and save again?
or, in general the plugin will be reloaded when you save it, if it is a top level module.

0 Likes
#3

You can also use Package Control to disable and then enable the package again.

But why do you want to reload it from console? If you change a plugin, ST automatically reloads it to work with the updated version. It just doesn’t work for plugins located in sub folders. To reload such plugins I use https://packagecontrol.io/packages/AutomaticPackageReloader But you need to know there are still some edge cases which prevent python to reload sub modules correctly sometimes. Especially renamed modules or global variables are problematic.

I use a key binding to quickly reload modified plugins

	// Automatic Package Reloader
	{
		"keys": ["ctrl+f5"],
		"command": "package_reloader_reload"
	},
1 Like
#4

But you need to know there are still some edge cases which prevent python to reload sub modules correctly sometimes. Especially renamed modules or global variables are problematic.

When you talk about this, what do you mean? Asking you cos today after spending a fair ammount of time trying to narrow a bug I’ve been able to come up with some mcve code that will consistently allow to freeze-up SublimeText x64 (at least build 3176), steps to do so:

  1. Install automatic package reloader and set "reload_on_save": true on settings
  2. Uncompress this foo package on Packages\foo
  3. Open start.py and press save a few times without touching the code, do it as fast as possible till Sublime freezes… If you’ve have the console opened you should see eventually the line where Sublime will hang

It looks to me like a race condition issue and I’m not sure if the problem is because Automatic Package Reloaded is buggy… or because some of these methods https://www.sublimetext.com/docs/3/api_reference.html#sublime.Settings.

Anyway, please let me know more about the edge cases you were talking about on your comment… Basically I do hate using global variables on Sublime text code but sometimes I find it specially useful when creating memory caches or using a “Singletons” across modules…

PS: Sometimes it takes a bit of patience to freeze sublime… another times will be a matter of few seconds (at least on my box)

0 Likes
#5

I ran into issues with reloading plugins with sub modules, each time after renaming modules or globals.

Renamed globals causes the old instances to keep alive and being used rather than the new renamed ones. Can’t recall the details, but depending on usage the old ones were still used or sometimes the code just failed because the new globals were not created.

Same can happen after renaming (sub-)modules. Sometimes the reload failed, because python tried to load something which no longer existed or some imports seemed to still point to old no longer existing modules causing failures.

The process of reloading a sublime text package consists of several more or less expensive tasks to ensure ST unloads existing hooks (EventListeners, Commands) and updates them after reloading the submodules is done. This process takes some time and may fail if you trigger that process too quickly after each other.

As package reloader hooks deep into pythons internals to handle the sub module reloading correctly, which was never meant by design I woudn’t call that a bug. It’s more like a hack, which works well enough if used with care. If a second call intercepts the import loop of a prior reload unpredictable things might happen.

Maybe package reloader should check for repeated requests to reload plugins and drop them if a prior one is still on the fly.

3 Likes
#6

Maybe package reloader should check for repeated requests to reload plugins and drop them if a prior one is still on the fly.

BPL posted a issue on GitHub. This is also the solution which I proposed.

1 Like
#7

@deathaxe Thanks for that clarification! Alright, I understand now… yeah, I know what you mean by that, sometimes I’ve also experienced issues because renaming modules and globals and I wasn’t very sure what could be the exact reason, I recall some errors would go silently and mostly of the times I’d end up restarting sublime just to be sure the package errors would shown on the console properly.

That said, I think this case is somehow different. For instance, the mc[v]e I’ve posted tries to showcase a deadlock that I think is caused by trying to use the sublime settings functions family at loading time (evaluated and stored on global variables). The problem with my example is that reproducing the issue isn’t an easy task and that’s one of the most painful bugs that can happen when coding stuff.

Bugs that you can’t reproduce deterministically are the worst kind and after a lot of years of coding I wouldn’t know really what’s the best way to go around them… For instance, right now I’m using this little snippet [sublime.set_timeout(lambda: window.run_command("save"), i*100) for i in range(50)], but it won’t guarantee a deadlock to be shown easily… maybe after 1 or 2 executions of the snippets, or maybe more, who knows… I really hate these non-deterministic bugs :frowning:

Why do I insist so much on been able to reproduce it? Well, if my package contains some initialization code that could produce deadlocks when been reloaded I’d like to know that fact for sure. There isn’t anything more disturbing that being in the middle of a coding session and suddenly sublime freezing out. That’s really disturbing and leaves you with the feeling that your package is really fragile. I like to be sure that no matter how many times I reload my package Sublime won’t hang out, that’s the minimal quality requirement of my code (at least to me)… Another different issue is crashing at runtime, well, that’s “ok”… but at loading time? No thanks :slight_smile:

Anyway, as randy said I’ve opened a couple more issues talking about this stuff:

Hopefully I’m not the only one that I find this stuff quite interesting and relevant. So, If you want to add some pearls of wisdom there be my guest… Being able to reproduce the issue consistently (spawning a little command on sublime console) would be really awesome btw, so… :wink:

Anyway, ty for the clarification.

0 Likes
#8

maybe this:

>>> import sublime_plugin
>>> sublime_plugin.reload_plugin('my_plugin')
0 Likes
#9

Would reload python code from modules in the package root only! Changes in packages (sub directories) would be ignored as already in python’s code cache. This is what ST actually calls automatically if you change code of a module in your package root and save it.

0 Likes