Formally, Technically Document All Plug-in System Dependencies
Posted: 09.07.2026 06:54
Cud plug-ins should record their dependencies in some way that follows pixi or uv standards.
The recent LSP Client update caused Cud to emit console errs, because I lacked wcmatch and bracex. Only the LSP Client history file told me so. Not even its readme listed deps. And only the 2026.07.08 stanza stated anything. There is no standard location for such information, even in history files; it's ad-hoc.
Ad-hoc history does not assist automation by tools like uv. Python deps are buried in obscure files that average people will not understand, even if found.
Even with sysadmin privs, one can hit issues. For me, the missing packages do exist in Void Linux, but are several years stale. Void fails horribly keeping Python libs up-to-date. Even Debian has more recent versions.
Regardless, I installed what Void offered, and then downloaded the latest from upstream, overwriting Void's files in /usr/lib/python3.14/site-packages/wcmatch and /usr/lib/python3.14/site-packages/bracex. The last step was xbps-reconfigure --force python3-bracex python3-wcmatch to recompile. Such hacking is not recommended, but the alternative is to run ~3-year-old Python libraries updated since with important bug-fixes.
So, these are gotchas Linux users can encounter. First, finding the missing deps in obscure Cud files. Second, working around bad distro management and/or missing packages.
I want to manage Python deps in Cud with pixi or uv. Cud should consider documenting plug-in dependencies in a formal way. That alone would be a help. Every plug-in should list external dependencies in a stand-alone file.
Thanks!
The recent LSP Client update caused Cud to emit console errs, because I lacked wcmatch and bracex. Only the LSP Client history file told me so. Not even its readme listed deps. And only the 2026.07.08 stanza stated anything. There is no standard location for such information, even in history files; it's ad-hoc.
Ad-hoc history does not assist automation by tools like uv. Python deps are buried in obscure files that average people will not understand, even if found.
Even with sysadmin privs, one can hit issues. For me, the missing packages do exist in Void Linux, but are several years stale. Void fails horribly keeping Python libs up-to-date. Even Debian has more recent versions.
Regardless, I installed what Void offered, and then downloaded the latest from upstream, overwriting Void's files in /usr/lib/python3.14/site-packages/wcmatch and /usr/lib/python3.14/site-packages/bracex. The last step was xbps-reconfigure --force python3-bracex python3-wcmatch to recompile. Such hacking is not recommended, but the alternative is to run ~3-year-old Python libraries updated since with important bug-fixes.
So, these are gotchas Linux users can encounter. First, finding the missing deps in obscure Cud files. Second, working around bad distro management and/or missing packages.
I want to manage Python deps in Cud with pixi or uv. Cud should consider documenting plug-in dependencies in a formal way. That alone would be a help. Every plug-in should list external dependencies in a stand-alone file.
Thanks!