Charlie Marsh Profile picture
Jul 3 3 tweets 1 min read Read on X
The uv build backend is now stable, and considered ready for production use.

An alternative to setuptools, hatchling, etc. for pure Python projects, with a focus on good defaults, user-friendly error messages, and performance.

When used with uv, it's 10-35x faster. Image
Try it out by setting your project's build system, or running `uv init --build-backend uv`:

```toml
[build-system]
requires = ["uv_build>=0.7.19,<0.8.0"]
build-backend = "uv_build"
```

(In a future release, we'll make this the default.)
One underrated implication here: we can now build and publish your package without running or even installing Python.

In pure Rust, we can build your Python package, install it, publish it to a registry, etc.

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Charlie Marsh

Charlie Marsh Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @charliermarsh

Jan 29
We’re building a new static type checker for Python, from scratch, in Rust.

From a technical perspective, it’s probably our most ambitious project yet. We’re about 800 PRs deep! Image
Like Ruff and uv, there will be a significant focus on performance.

The entire system is designed to be highly incremental so that it can eventually power a language server (e.g., only re-analyze affected files on code change).
Performance is just one of many goals, though.

For example: we're investing heavily in strong theoretical foundations and a consistent model of Python's typing semantics.

(We're lucky to have @carljm and @AlexWaygood on the team for many reasons, this is one of them.)
Read 7 tweets
Dec 3, 2024
python-build-standalone has exploded in popularity, with over 70M downloads all-time.

But what is a "standalone" Python build?

It wasn't obvious to me at first! Initially, I didn't understand what problem was being solved or why it mattered... Image
First, some context on the problem.

Normally, when you build CPython on Linux or macOS, several system paths are hardcoded into the binary.
This is fine if you're building and installing Python on a single machine... but it's a problem if you want to pre-build Python and then distribute it to other machines, since those paths might be wrong!
Read 14 tweets
Aug 20, 2024
Today, we're shipping a series of features that move uv beyond a pip alternative, and into an end-to-end solution for managing Python projects, command-line tools, single-file scripts, and even Python itself.

A single, unified tool. Like Cargo, for Python.

It's very fast. Resolving the Transformers project with all optional dependencies enabled, without (top) and with (bottom) caching.
First, projects.

With `uv lock`, you can now generate cross-platform lockfiles based on standards-compliant metadata.

uv's lockfile generates a single, deterministic solution for every possible target environment. This was really hard to build.
Read 12 tweets
Feb 15, 2024
Announcing uv: an extremely fast Python package installer and resolver, written in Rust.

uv is designed as a drop-in alternative to pip, pip-tools, and virtualenv.

With a warm cache, uv installs are near-instant. Here, it's > 75x faster than pip and pip-tools. Benchmarking uv against other Python packaging tools.  See: https://github.com/astral-sh/uv/blob/0780afff95b72c66d9cc8cf955acae2e4857acd1/BENCHMARKS.md
uv is an alternative to pip-compile, with a drop-in compatible API.

In our benchmark, it's 10x faster without any caching, and > 100x faster with a warm cache.
Read 13 tweets
Feb 4, 2024
A collection of (sometimes contradictory) beliefs I've developed on building fast software...
Sometimes, performance just doesn't matter. If I make some codepath in Ruff 10x faster, but no one ever hits it, I'm sure it could get some likes on Twitter, but the impact on users would be meaningless.
And yet, it's good to care about performance everywhere, even when it doesn't matter. Caring about performance is cultural and contagious. Small wins add up. Small losses add up even more.
Read 10 tweets
Jun 19, 2023
There's an extremely interesting conversation going on in Python right now around the future of performance.

It's centered on @colesbury's PEP 703, which makes the GIL optional (to be removed entirely in the future), but comes at a cost.

Here's my summary...
For context: The CPython interpreter isn't thread-safe, so the global interpreter lock ("GIL") exists to ensure that only one thread is actually executing code at a time.

PEP 703 includes changes to (1) make the interpreter thread-safe and (2) make the GIL optional.
It's agreed that removing the GIL would have an enormous performance benefit on multithreaded code. It would change Python dramatically.

But there appear to be two main hesitations to the PEP.
Read 16 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(