Page 1 of 1

Formally, Technically Document All Plug-in System Dependencies

Posted: 09.07.2026 06:54
by Random Void User
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!

Re: Formally, Technically Document All Plug-in System Dependencies

Posted: 09.07.2026 21:31
by main Alexey
about pixie or uv: I don't know what to suggest you here. i don't use these tools yet.

ok, let's create file like readme/dependencies.txt. let's talk about this file contents.
on the example of LSP plugin.
file may be like:

---
Windows
=======
plugin needs "pydantic" module version 2.
for Python 3.8, it is preinstalled in the plugin's subfolder.
for other Python versions, download this module from PyPI.org and
put it into <.......not sure what here...>

Unix-like OS
============
plugin needs additional Python modules installed into OS Python:
- pydantic (version 2)
- wcmatch
- bracex
typical installation from terminal is:

$ pip install pydantic
$ pip install wcmatch
$ pip install bracex

Re: Formally, Technically Document All Plug-in System Dependencies

Posted: 11.07.2026 18:49
by main Alexey
As temp solution for LSP plugin:
- added 'Dependencies' topic into readme.txt
- uploaded plugin's zip to SourceForge without version change