Repository navigation
Schema appears incorrect for rope.extensionModules #590
Description
Been attempting to audit Emacs eglot configurations vs. pylsp logs and behaviors (a frustrating and time-consuming process).
pylsp code says; e.g.
return {
"rope": {"extensionModules": MODULES},self.__rope.prefs.set(
"extension_modules", rope_config.get("extensionModules", [])Yet the schema says string and not array.
"pylsp.rope.extensionModules": {
"type": [
"string",Is this innocuous or does it have negative effects? Do the rest of the entries need auditing is a question this raises...
Activity
AbhiramVSA commentedon Oct 30, 2026
The current schema still describes
pylsp.rope.extensionModulesasstring | null, whileWorkspace._rope_project_builder()passes this setting to Rope'sextension_modulespreference.CONFIGURATION.mdrepeats the string type.A check against the schema at
a362006withjsonschema4.10.3 rejects["numpy", "scipy"]and[], but accepts"numpy"andnull. This confirms that clients which validate settings against this schema reject the module-list form reported here. It does not change the server's runtime behavior.I can prepare a focused schema correction to an array of module-name strings or null, retain the null default, and regenerate the configuration table. The regression checks can cover populated and empty arrays, null, and invalid scalar or non-string entries. The related open PRs #664 and #670 address folder creation and dictionary merging, rather than this schema type.
Is
array[string] | nullthe intended contract for this setting, or does the scalar-string form need compatibility support?shipmints commentedon Oct 30, 2026
If you're asking me, yes an array should be supported. The name of the option is plural "extension_modules" and seems intended to accept a list.