How to handle dependencies that want to expose settings

[rchl]

I'd like to discuss the possibility of supporting libraries that want to expose settings (and potentially just any other components that a normal package can expose).

As we know, both lsp_utils and mdpopups (anything else?) want to expose corresponding dependency settings apart from the dependency itself. With PC4 this now longer works. I can't think of any good alternatives for how to handle those currently. lsp_utils could potentially be integrated into LSP itself but that wouldn't really work for mdpopups.

Should there maybe exist a way for a dependency to specify a list of files that should be copied to Packages directory?

CC: @rwols @deathaxe @facelessuser @predragnikolic @jwortmann @jfcherng

[deathaxe]

A possible solution for lsp_utils would be a separate helper package, such as LSP-utils, which provides the settings. It would need to be anounounced and installed separately though. Maybe at some point in future, it can be specified as being required by all the LSP-... helpers, which also require lsp_utils.

Same would theoretically work for mdpopups, but it only ships a Preferences.sublime-settings and a sublime-package.json which would be relevant. The latter one could be searched for and loaed by LSP-json. It would require some filesystem traversal logic to collect those files though. Nothing else Package Control needs to do to handle libraries. Once the transition to python 3.8 is completed, it should be easily doable via pathlib's glob support.

---

Otherwise Package Control would need to somehow identify "ST package style" parts of a dependency and auto-maintaina a ST package for them. That's probably not feasable for various reasons:

1. There's no sane/safe way to identify all relevant files consistently, if we assume not only some *.sublime-* files being affected.
2. it's probably not safe to just put everything unidentified into a ST package and install it.
3. python libraries can now have the same name as ST packages. Hence naming conflicts would be possible. (e.g.: "six" or "Markdown")
4. Dependencies were primarily designed to enable normal python packages to be installed and re-used by plugins. All but 2 dependencies comply with that pattern.
5. Dependencies/Libraries maintaining (creating/updating/removing) ST packages is somewhat upside-down

It's up to plugin/library authors to find ways to achieve that.

[deathaxe]

The following snippet illustrates an example how to search for certain files in libraries, if required. Note it's rather naive and returns duplicates in case a library is installed in multiple environments.

import sublime

from pathlib import Path

def get_sublime_package_json():
    lib_root = Path(sublime.packages_path()).parent / "Lib"

    if int(sublime.version()) > 4000:
        lib_dirs = ["python33", "python38"]
    else:
        lib_dirs = ["python3.3"]

    for py in lib_dirs:
        for fname in (lib_root / py).glob("*/sublime-package.json"):
            yield fname

print(tuple(get_sublime_package_json()))

[jwortmann]

With PC4 this now longer works. I can't think of any good alternatives for how to handle those currently.

mdpopups doesn't expose any commands in the command palette, and it reads its settings from Preferences.sublime-settings, so they still work. Just the shipped Preferences.sublime-settings file is obsolete now and could be removed from the repository.

So a simple solution for dependencies/libraries that want to use settings seems to be to just read from Preferences.sublime-settings, and to define the default setting values within the Settings.get/Settings.setdefault calls. They could also still use a different file name like lsp_utils.sublime-settings, but this seems inconvenient now, as there is no more menu or command palette entry to create and open this file.

Python 3.3

sublime.load_settings('Preferences.sublime-settings').get('setting_name', 'default_value')

Python 3.8

sublime.load_settings('Preferences.sublime-settings').setdefault('setting_name', 'default_value')

(get of course also still works in the 3.8 API, but is undocumented)

It would probably be a good idea to describe the available setting in the Readme page, and mdpopups already has descriptions for the settings in its documentation.

Regarding the sublime-package.json files from libraries; I'd support that this should be handled by LSP-json, with something like the example pointed out above.

[facelessuser]

Mdpopups can just use get in all places it has to. setdefault is the most unintuitive name for a get replacement. I hope they never remove get support.

[jwortmann]

There wasn't any suggestion for mdpopus to switch from get to setdefault. This was just an example what I would personally use for a package or dependency which targets the Python 3.8 API exclusively. In fact it would break support for Python 3.3 packages if it was used in mdpopups. I'm sure they will never remove support for Settings.get even in the 3.8 API environment, because it would be a breaking change and there is nothing to be gained from it. It's just that get is an undocumented function now, and there exist an alternative.

[facelessuser]

I wasn't saying that was suggested. I was saying we (mdpopups) could ensure we use get. I was saying as a side note, I hate the name setdefault.

[rchl]

I am not fully satisfied with having to use global preferences. Specifically with the fact that in that case the reference for the settings has be outsourced to some less convenient place like a readme or github. It requires extra actions from the user to see those.

LSP-json can help somewhat (once it supports reading schema from libraries) but it's not really great for getting an overview of the available settings. Especially within global preferences where a ton of other settings are also available...

[FichteFoll]

As far as I'm aware, LSP is going to integrate/rewrite lsp_utils into the main LSP package in the long term and already spearheaded this change by integrating its settings file into the main repo (via sublimelsp/LSP#2395).

[rchl]

Yeah, this issue doesn't affect lsp_utils anymore. Feel free to close unless you think it should still be addressed somehow.

[deathaxe]

With regards to a statement of what dependencies are at #1663 (comment), I am closing this issue.

The only possible extension would be adding a feature to let packages depend on each other.