Closed kaste closed 8 months ago
Let's see if the tests pass as it works locally at least.
Okay, would have been nice but that breaks it for ST3. (macOS failures are unrelated.)
Well, the first commit here tried the reloader from AutomaticPackagerReloader which failed for ST3. The second commit tries the reloader from GitSavvy. This passes (except for MacOs as expected).
The GitSavvy reloader is simpler than the current (failing) version in this repo (I think), and like an order of magnitude simpler than the one on AutomaticPackageReloader. I'm not a fan of this getting more and more complicated as it is code basically nobody understands and can test thoroughly enough.
I will probably switch GitSavvy
to the "new", unified and trivial simple procedure @\deathaxe proposed to me and elsewhere. (As soon as I don't need any features from the last reloader. Basically with the new approach we loose some hot reloading feature as the modules don't get replaced "in-line" anymore. This in contrast to just saving a plugin because Sublime will reload the module in-place.) However, @\deathaxe's approach wouldn't work here anyway as we need to target any package and reload it "at our will".
Fixes #228
Since the Package Control update to v4 our reloader is broken. E.g.
PackageManager()._is_dependency(pkg_name)
throws as it's not there anymore. (Note the leading_
telling us to not use this method.)For now, copy the reloader from
AutomaticPackageReloader
GitSavvy
as it seems "newer" and works at least locally.