Pydantic Breaks Again Python 3.14.2

[badrelmers]

for Linux: it is not easy and I don't think even I can get/install it. in portable python for Linux we need libpython*.so file. tools like 'uv' don't install .so file, AFAIK.

how? i always used portable python in linux few years ago, there is dozens of ways to get one, for example you can directly download the ones from the creator of uv from here,
https://github.com/astral-sh/python-bui ... e/releases
they are portable because the executable is compiled to look for its shared libraries in a relative path not system-wide /usr/lib , and they come with libpython*.so included inside them in lib folder, i just downloaded now one of them and they still offer the *.so file

one can even use the ones from appImage, egenix pyrun, pyenv ...etc and multiple other places.

[main Alexey]

great! thanks for this info. ok, portable linux-python exists.

[Random Void User]

I'm glad to hear good news on LSP v2 porting progress.

The pylib__linux field might indeed be modified somehow. It's a weird way to parameterize Python in the first place. I change it regularly when I boot a live Linux ISO and install CudaText.

I am almost reaching an opinion that CudaText should adopt uv for all plug-ins. $UV_PYTHON_PREFERENCE can prioritize the system Python over any others installed. Meanwhile uv could eliminate similar dependency problems, which I have encountered before, whereby a plug-in fails because my system lacks a dep. Instead of a user needing to (a) find, and then (b) install a missing dep, uv could do it automatically; up to a separate Python version if needed. Righ now, CudaText plug-ins do not have explicit dependency definitions. At best there are comments and error messages. There is more involved than just dropping some portable Python and modding some $PYTHON_* vars.

CudaText using Pascal is odd for an app so reliant on Python. Maybe wxPython could work. But I love CudaText UI customization. I have a highly modified menu layout.

Anyway, here are some third-party quotes pulled from articles on uv. Nothing below is mine. Thanks!


A year of uv: pros, cons, and should you migrate - Yes, probably.

Because I'm a freelancer dev, and also a trainer...I've seen all other tools fail spectacularly. pyenv, poetry, pipenv, pdm, pyflow, pipx, anaconda...PATH, PYTHONPATH, terrible naming conventions, having multiple Python versions on the same machine, optional packages on Linux, and Python being a system dependency create a thousand ways to shoot yourself in the foot....uv brought...more than Python project management....uv capabilities...alter deeply the way you use Python scripts....Personally, I used to manage a gigantic venv just for my local scripts, which I had to kill and clean every year. Now, you are free to use whatever. It's fast. Transparent. Efficient. Self-descriptive.


Hacker News Review

With the advent of uv, I'm finally feeling like Python packaging is solved. As mentioned in the article, being able to have inline dependencies in a single-file Python script and running it naturally is just beautiful.

One other key part of this is freezing a timestamp with your dependency list...This has also let me easily reconstruct some older environments in less than a minute, when I've been version hunting for 30-60 minutes in the past.

uv uses a platform independent resolution for its lockfiles supports features that Poetry does not

There's like 5 different ways to create virtual environments. With uv, you don't have to care about any of that. The venv and your Python install are just handled for you by 'uv run', which is magic.

conda user for 10 years and uv skeptic for 18 months. I get it! I loved my long-lived curated conda envs. I finally tried uv to manage an environment and it's got me hooked....No more meticulous tracking of a env.yml or requirements.txt just 'uv add' and 'uv sync' and that's it! I just don't think about it anymore

A big thing that trips people up until they try to use a public project (from source) or an older project, is the concept of a dependencies file and a lock file.
The dependency file (what requirements.txt is supposed to be), just documents the things you depend on directly, and possibly known version constraints. A lock file captures the exact version of your direct and indirect dependencies at the moment in time it's generated. When you go to use the project, it will read the lock file, if it exists, and match those versions for anything listed directly or indirectly in the dependency file. It's like keeping a snapshot of the exact last-working dependency configuration. You can always tell it to update the lock file and it will try to recaclulate everything from latest that meets your dependency constraints in the dependency file, but if something doesn't work with that you'll presumably have your old lock file to fall back on _that will still work_.
It's a standard issue/pattern in all dependency managers, but it's only been getting attention for a handful of years...It has the side effect of helping old projects keep working much longer though.

uv can handle things like downloading the correct python person, creating a venv (or activating an existing venv if one exists) and essentially all the other cognitive load in a way that's completely transparent to the user. It means you can give someone a Python project and a single command to run it, and you can have confidence it will work on regardless of the platform or a dozen other little variables that trip people up.

I am a casual python user, and for that I love uv. Something I haven't quite figured out yet is integration with the pyright lsp - when I edit random projects in neovim, any imports have red squiggles. Does anyone know of a good way to resolve imports for the lsp via uv?
I start a shell with "uv run bash" and start neovim from there. I'm sure there's other ways but it's a quick fix and doesn't involve mucking around with neovim config.
That's brilliant, thanks
EDIT - 'uv run nvim' works also


A Deep Dive into UV: The Fast Python Package Manager | Better Stack Community
Unlike tools like pyenv, uv integrates Python version control with dependency management, ensuring a consistent and optimized development experience.


UV — Intuitively and Exhaustively Explained

[main Alexey]

reviews of 'uv' were interesting. thanks!

> almost reaching an opinion that CudaText should adopt uv for all plug-ins. $UV_PYTHON_PREFERENCE can prioritize the system Python over any others installed

what is your concrete suggestion for the Cud code? I don't understand HOW should I integrate uv.

[Random Void User]

It would take thought and experiments. Probably several ways exist, but only one is optimal. Remember to consider plug-ins with deps outside Python, like Spell Checker needing hunspell (which is in CondaForge). I think it's really a question for experts on uv's forum.

CudaText could test whether uv exists, and if not, prompt the user for installation. The dialog should say it's needed for plug-ins. I'd allow the user a choice of where to install uv. Since uv uses hard links in its cache for de-duplication, the storage location is not portable by mere copying.

Each plug-in would run through uv in any case. Perhaps inline scripting could work?
https://osc.garden/notes/uv/#use-uv-as- ... ebang-line
https://packaging.python.org/en/latest/ ... t-metadata

[main Alexey]

currently Cud makes in-memoty PythonEngine object. it has method e.g. ExecStrings to run string-list as a script. how can i change it to 'run uv'. i don't understand.

[Random Void User]

I'm not familiar with Lazarus Pascal bindings to Python. Why do plug-ins turn into strings? They are just Python scripts on disk.

The various uv calls are external system calls, and uv will handle all needful Python environments on demand. Cud can invoke plug-ins like Bash scripts. As suggested above, modified shebang headers invoke uv instead of Python. That approach may or may not be optimal, but seems viable at first blush.

[main Alexey]

we are stuck here, with 'uv' integration. because I cannot imagine how to embed this uv into current code. Cud's code is complex, it has many memory objects loaded from Python engine. how to change this code- IDK (i don't know). python plugins are not only files on disk, they are giving memory-objects, which Cud tracks, e.g. to not reload plugin twice when on_caret event arrives to a plugin 2nd time.

[main Alexey]

Cud loads libpython*.so (on Windows: python*.dll) and gets library function pointers. it uses these pointers to exec scripts, but not only for this. it can enumerate python 'locals' sometimes and load modules into memory and track module's objects. how this can be changed 'to uv'- i don't know.

[Random Void User]

Cud seems to need an embedded Python, which uv could supply and manage, along with all the plugins. I would look into wxPython as an alternative GUI framework. Lazarus Pascal may impose needless constraints with its Python bindings. Of course porting to wxPython is a bigger project, but might pay dividends in Python access and ease of use.