bolha.us is one of the many independent Mastodon servers you can use to participate in the fediverse.
We're a Brazilian IT Community. We love IT/DevOps/Cloud, but we also love to talk about life, the universe, and more. | Nós somos uma comunidade de TI Brasileira, gostamos de Dev/DevOps/Cloud e mais!

Server stats:

252
active users

#uv

11 posts11 participants1 post today

- thisdavej.com/share-python-scr

Sharing single-file Python scripts with external dependencies is now easy thanks to uv and PEP 723, which enable embedding dependency metadata directly within scripts. This approach eliminates the need for complex setup tools like requirements.txt or package managers, making script distribution and execution seamless and simplifying deployment while maintaining flexibility and efficiency.

I'm in love with uv. Seriously, the tool is small yet packs a punch with features.

I'm writing an article for Fedora Magazine about the cool things you can do with uv, here is the source code (with the article in markdown) for your enjoyment:

github.com/josevnz/tutorials/t

Tutorials. Contribute to josevnz/tutorials development by creating an account on GitHub.
GitHubtutorials/docs/Enhancing_Your_Python_Workflow_with_UV_on_Fedora at main · josevnz/tutorialsTutorials. Contribute to josevnz/tutorials development by creating an account on GitHub.
#uv#python#textual

Porównajmy backendy #PEP517 dla paczek napisanych w samym Pythonie:

#flit-core: 51 KiB archiwum źródłowe, bez zależności, instaluje się 0,05 s, ~150 KiB po zainstalowaniu, działa wszedzie
#UvBuild: 300 KiB archiwum, wymaga ~250 zależności crate (54 MiB pobierania, ~600 MiB w .cargo), buduje się 1 min 20 s (na 12-wątkowym procesorze), 4,2 MiB po zainstalowaniu, wspiera kilkanaście platform

I oczywiście, że flit-core ma szerszą funkcjonalność. Ale jestem przekonany, że gdzieś ktoś potrzebuje zaoszczędzić te kilka milisekund budowania paczek Pythona.

Let's compare #PEP517 backends for pure #Python packages:

#flit-core: 51 KiB sdist, no dependencies, 0.05 s to install, ~150 KiB after installing
#UvBuild: 300 KiB sdist, requires ~250 crates (54 MiB download, ~600 MiB .cargo directory), 1 min 20 s to install (on a 12-thread system), 4.2 MiB after installing

And yes, you guessed right, flit-core has more functionality. But I'm sure that there are performance-critical wheel building workflows that will benefit from these few milliseconds shaved off wheel building time.

un article du blog "bite code" (que je vous recommande de suivre ou de fouiller - plein de choses intéressantes sur les #tests aussi, par exemple) sur un retour d'expérience sur github.com/astral-sh/uv, le gestionnaire de projet #Python de @charliermarsh, après un an d'utilisation de #uv dans différents contextes : bitecode.dev/p/a-year-of-uv-pr

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

À suivre : un billet dédié à ses conseils d'utilisation de uv.

An extremely fast Python package and project manager, written in Rust. - astral-sh/uv
GitHubGitHub - astral-sh/uv: An extremely fast Python package and project manager, written in Rust.An extremely fast Python package and project manager, written in Rust. - astral-sh/uv
Continued thread

My current pondering is whether we should go with `uv run --offline` invocations in our docker images 🤔 with the idea of improving efficiency (don't generate internet traffic) and stability (don't rely on anything external).

#uv

Edit: removed "builds"

Clarification: When we *use* a docker image, by calling the internals with `uv run --offline` we'll _just_ invoke our Python tool, and prevent uv from checking / installing packages.

Have just found one of our work Docker container images was missing a call to `uv sync` to install Python package dependencies.

We didn't see any problems because all calls we do are wrapped in `uv run`, but this meant that every time we were using the container image, it was first taking about 0.25s to install the 67 package dependencies.

Again - 0.25s isn't great overhead, and really it's not a speed problem. The image is a validator and takes about that long to validate a file.

BUT...