How to split main.py into multiple modules? about lsp HOT 3 CLOSED

This is done, developers will need to install "AutomaticPackageReloader" to see code changes reflected in Sublime Text.

from lsp.

As LSP has to handle quite a lot of different stuff, splitting it into several modules is unavoidable. There are several packages out there, which could be used as an example to see how it works. You might have a look into GitSavvy or GitGutter which both do so.

There are some major facts to pay attention to, before splitting the main.py.

1. Sublime Text actively loads all modules and API classes from the root of each package (only). This is good and bad as well.

2. Modules living in the root of a package should not be included into other modules as ST will create two instances of them otherwise. One instance is created by python's import statement and one by ST's core when searching for API classes. This is known as the "double loading bug" and is of interest when working with global variables.

3. Modules living in a subdirectory are ignored by ST and therefore can be imported as often as desired without creating several instances. By placing an init.py into each sub directory python will handle them as one big file in the end. The drawback of that is ST won't automatically reload any module after modification or upgrade.

I decided to put all modules into a subdirectory anyway as there are more advantages then disadvantages.

Pros:

• The package publishes only the least required classes to ST.
• Loading time of the package is smaller then with multiple files in the root (no double loading)
• Smaller modules can be maintained easier and function may be grouped by categories

Cons:

• After modification you must manually trigger reloading the modules.
  I use AutomaticPackageReloader for that. Not too inconvenient.
• ST needs to be restarted after upgrading the package to apply the changes.
  I added a reloader module to GitGutter, which does nearly the same as AutomaticPackageReloader and is triggered after Package Control upgrade.

About the size of each module - it depends on complexity of each module. I'd create a module for each type of function and start splitting any further if it becomes too big. pylint starts complaining if a package exceeds 500 lines of code by default. Same with number of attributes of a class (max 12 or 15), or branches in a function (12 or 15). These values may be used as a guideline to make decisions.

I would suggest a common folder with all modules in it. I called it modules in GitGutter. With a single plugin.py in the root, the console will then show

Reloading plugin LSP.plugin ...

in the console upon startup.

from lsp.

With a look onto the ongoing development and size of main.py, a module structure should be one of the next steps to keep the package maintainable.

Maybe something like:

• general language-server-protocol stuff
  • client
  • protocol constants
  • ...
• library
  • commonly used functions
• intermediate functions which handle certain server responses
  • diagnostics
  • references
  • goto definitions
  • code actions
  • completions
  • docstring popup rendering (handle RST, markdown, Google Docstrings, ...)
• sublime API
  • commands
  • events

from lsp.