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?

[badrelmers]

Random Void User
Sorry, I do not know why I did not see your message when I posted my previous message! maybe I did not refresh. github teached me to become lazy because it auto refresh the new messages without needing a new page refresh, i did not participate in forums for more than 15 years lol

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.

yes, I understand, but I do not know even how uv can be integrated with Cudatext, this is not something that can be done by a plugin, it must be done by cudatext itself, it is not difficult anyway it is just a matter of integrating uv with cudatext and auto downloading the needed version based on the user setting or the default setting, but I m not one of the cudatext maintainers to take that decision. in windows we can choose the version we want already, it is integrated with cudatext, I do not know why it was not done in that way for linux too. Alexey knows better.

anyway I m upgrading the plugin to use pydantic v2 and i m getting good results thanks to God, it is not as painful as I thought in the beginning. I think it will be ready soon if God wills

[badrelmers]

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?

oh! I did not know about pylib__linux, this already solve the problem in this thread! no need for uv in this case.
but i did not understand your question very well, what is the problem in using the preferred user setting pylib__linux? if the user decide to use it then just use it, cudatext should not make that decision, because other plugins may need a newer python version, so it is the user responsibility to know its ecosystem and what it needs.

maybe a better solution is to use uv as "Random Void User" suggested, and allow each plugin to have its isolated python version and environment, and use the default python if not configured.
or allow the plugins to have a setting where the user set the wanted python versions, something like

Code: Select all

pylib__linux:  [{"default": "/path/to/python1"}, {"cuda_lsp": "/path/to/python2"}, ...etc]

, then the plugin make the decision to use the needed python version or ask the user to set it if the plugin could not find the needed version. but this means that cudatext will have to load two or more pythons at the same time, i do not know how well this can go, but with the newer python versions (3.4+) a full isolation is possible using only python no need to any other third party solution, using:

Code: Select all

PYTHONNOUSERSITE 
PYTHONUSERBASE 
PYTHONHOME 
PYTHONPATH
PIP_CACHE_DIR 
PIP_ISOLATED 
PIP_NO_CACHE_DIR

this is what i use in windows, maybe linux is different, but it should not!

[main Alexey]

as I understand the python usage, it is NOT possible to have separate pythons (imported from several different versions, 3.12 and 3.14) for the CudaText. app cannot handle 2 instances and send python events+commands to both instances.