Pydantic Breaks Again Python 3.14.2

[Random Void User]

I lack a GitHub account and won't contract with Microsoft. So here I'll close by correcting these GitHub remarks:

UV have nothing to do with this problem and cannot solve it, the problem is that the lsp plugin need to be upgraded to V2, UV is just another venv/pyenv + pip + other things, a package and environment manager to separate environments to ease the development and its dependencies!...pydantic_v1, it is a good solution, but unfortunately again it does not support python 3.14... the only solution is to upgrade the plugin to V2

We agree that LSP needs fixing for Pydantic v2. However the statement that uv has nothing to do with this versioning problem, and cannot solve it, is 100% incorrect. Indeed, uv provides the only solution until LSP is ported to v2.

The uv system addresses deficiencies in venv, pip, pipx, et al. It can embed whatever necessary Python version LSP wants. The old "pip" or "venv" methods only work inside Python; uv installs Pythons too, not just packages.

So until LSP ports to Pydantic v2, the "v1 API" can work today. All the "v1 API" needs is a lower Python version than 3.14, which uv can install with Pydantic 2.

For that matter, uv could install Pydantic v1 with the last Python that most recently worked with v1. Then the LSP code will function without even touching it, right now.

Someone familiar with LSP code should decide which route is minimum work. I just explain here that uv provides two different ways to make LSP work now, with (a) almost or (b) exactly no changes. Of course, I still want LSP ported to v2.

If you're not familiar with uv, then you may not know pixi.sh either. It's like uv, and uses some uv code internally. However it handles more languages than Python. For strictly Python purposes, uv is best.

Thank you! I appreciate the interaction and look forward to CudaText improvements. It's a fantastic app!

[badrelmers]

I lack a GitHub account and won't contract with Microsoft. So here I'll close by correcting these GitHub remarks:

Ok, no problem, but forgive me if i do not see the next answers or forgot about this thread, i will have to remember that there is a thread and check from time to time if God wills.

So until LSP ports to Pydantic v2, the "v1 API" can work today. All the "v1 API" needs is a lower Python version than 3.14, which uv can install with Pydantic 2.

Thank you for elaborating on the capabilities of uv. I understand its value as a modern environment management tool.
However, I need to point out a logical contradiction in the proposed solution and how it relates to the entire premise of this thread.

The Paradox of Downgrading
1. The Initial Problem: You, as the original poster, opened this thread because the cuda_lsp plugin fails when running on Python 3.14.2. The explicit goal is to fix the plugin so it works with this new, current version 3.14. no?
2. The Proposed uv Solution: Your suggestion is to use uv to create a virtual environment that installs an older Python version (e.g., 3.12 or older) alongside a working Pydantic/LSP setup.
This proposed solution attempts to solve a problem that do not exist, by avoiding the problem that the thread was created to fix!.
• For Linux users, running any specific, older version of Python is a trivial task already handled by common tools like pyenv or simply installing the appropriate system package. No one is currently struggling to install Python 3.12.
• The actual challenge is that the plugin is incompatible with the future (Python 3.14.2). Suggesting we use uv to force a downgrade is essentially saying "the bug is not fixable, so please avoid the environment where the bug appears."

Conclusion: uv Does Not Fix the problem, the problem is as you titled it "Pydantic Breaks Again Python 3.14.2", so if you can install an older python then this is the solution.

The necessary fix remains: The cuda_lsp plugin must be updated to use Pydantic V2. This is the only path to genuine compatibility with Python 3.14.2 and ensuring the plugin's future viability.

[Random Void User]

My Python version detail was just debug info like the CudaText version blurb and Python console output; the usual practice in reporting bugs. It doesn't matter which version of Python runs Pydantic/LSP. Right now I have no working Pydantic/LSP setup. I can't use LSP in CudaText. That issue I care about.

Downgrading system Python would create more work than uv. My system uses Python 3.14 for other purposes. The distro sets the upgrade schedule for them. To downgrade system Python would be fighting the distro maintainers needlessly.

It is not trivial to install two Pythons on the same system without help from a dedicated tool like uv. It makes a Python environment isolated from the system. The Python in that environment can be any version, yet does not conflict with system Python. All it needs to run is Pydantic/LSP, nothing else. Research the differences with pyenv at your leisure. Similarities exist, but uv is in another league. Pros have moved to uv.

I did not suggest using uv to "force a downgrade," but as a handy stop-gap while work continues on porting LSP to v2. One can run system Python 3.14+ the whole while, plus a working Pydantic/LSP setup based on uv. Nobody needs to install Python 3.12 by hand, uv can do that automatically, unlike pyenv.

Sorry if the title confused. How would I rephrase it? "LSP Plugin Needs uv Rigging Until Ported to Pydantic v2" might explain the thought concisely.

Thanks!

[badrelmers]

I started working on upgrading the LSP plugin to use pydantic v2 and support python 3.14, I hope it will be ready soon if God wills.

[main Alexey]

how Cud will know that it must use downgraded Py 3.12 on system with option "pylib__linux": ...... (here is path to Py 3.14)?
does Cud need to change option "pylib__linux" to downgraded Py 3.12?
what if downgraded Py 3.12 don't have the .so (library) file?