charliermarsh (u/charliermarsh)

charliermarsh commented on Code formatting comes to uv experimentally pydevtools.com/blog/uv-fo... · Posted by u/tanelpoder

RossBencina · 2 days ago

What's wrong with the approach is that it goes against basic principles of the Python ecosystem. Python has always followed the policy of standardising mechanisms and allowing implementations to develop and peacefully coexist. The Python way fosters diversity of implementations. Note that uv itself would not be a reasonable project if not for Python's approach to diverse tooling.

You cite good examples where other languages have chosen to standardise tooling. We can discuss the pros and cons of that choice. But it is a choice, and Python already made a different choice.

charliermarsh · 2 days ago

All of our tools can be used independently and in coexistence with other tools. You can use `uv` with other build backends; you can use `virtualenv` to create your virtual environments, and `uv pip` to install into them; you can use `ruff` as a linter and `black` as a formatter, or `ruff` for both, or whatever. Here, similarly, you can use `uv` with `ruff`, or bring your own formatter. It's intentional for us that you can use the pieces that you want, and interoperate with other tools. But it's also intentional that we want using our tools _together_ to be a great experience. I think we can achieve both of these things. Or, at least, we're going to try.

charliermarsh commented on Code formatting comes to uv experimentally pydevtools.com/blog/uv-fo... · Posted by u/tanelpoder

zelphirkalt · 2 days ago

Developing a good and configurable formatter is a project almost as complex as uv's main focus, managing packages. As such it will divert time and attention from its main purpose and the outcome is questionable, considering how many bad formatters are out there. For example the "opinionated" black is terrible and has no awareness of semantics.

charliermarsh · 2 days ago

We already develop a formatter: Ruff (https://github.com/astral-sh/ruff). Ruff and uv are built by the same team. `uv format` is just an optional front-end to `ruff format`.

charliermarsh commented on Code formatting comes to uv experimentally pydevtools.com/blog/uv-fo... · Posted by u/tanelpoder

calmbonsai · 2 days ago

I see zero need for this given that excellent time-testing code formatting tooling options are already available.

This smacks of feature-creep and I won't be incorporating it into any pipelines for the foreseeable future.

charliermarsh · 2 days ago

`uv format` is just a front-end for `ruff format`. It isn't introducing a new formatter to the ecosystem or anything like that.

charliermarsh commented on Code formatting comes to uv experimentally pydevtools.com/blog/uv-fo... · Posted by u/tanelpoder

drdaeman · 2 days ago

Isn’t there `uv tool run ruff` already for this? Or `uv run ruff` if it’s a proper dependency? I’m not sure what’s the point of a special shortcut command, unless there are plans to make it flexible so it’ll be an abstraction over formatters (unifying ruff, black, etc).

charliermarsh · 2 days ago

Yeah, you can definitely use `uvx ruff` (an alias for `uv tool run ruff`) to invoke Ruff. That's what I've done in my own projects historically.

The goal here is to see if users like a more streamlined experience with an opinionated default, like you have in Rust or Go: install uv, use `uv init` to create a project, use `uv run` to run your code, `uv format` to format it, etc. Maybe they won't like it! TBD.

(Ruff is installed when you invoke `uv format`, rather than bundled with the uv binary, so if you never use `uv format`, there aren't any material downsides to the experiment.)

charliermarsh commented on Code formatting comes to uv experimentally pydevtools.com/blog/uv-fo... · Posted by u/tanelpoder

treyd · 2 days ago

Are they baked into the main executable or are they separate binaries (a la apt, cargo, etc)?

charliermarsh · 2 days ago

It's a separate binary -- we install Ruff if you invoke `uv format`. So if you don't invoke `uv format`, there's no impact on the binary size, etc.

charliermarsh commented on Code formatting comes to uv experimentally pydevtools.com/blog/uv-fo... · Posted by u/tanelpoder

0cf8612b2e1e · 2 days ago

But why do it? Keep each tool focused on its specific goal. Will there eventually be a call to deprecate ruff because it already exists in uv?

Both tools are still evolving enough that I would not want their individual release cycles to impact each other.

charliermarsh · 2 days ago

Good questions. I don't think we'd ever deprecate Ruff because `uv format` exists, and adding `uv format` won't have any impact on Ruff's release cycles or development. The analogy would be to Cargo: `cargo fmt` just runs `rustfmt`, but you can also run `rustfmt` separately if you want.

A lot of users just want a simpler experience. They want to install uv, run `uv run` to run their project, `uv format` to format it, etc. The idea here is to experiment with providing that functionality and see if folks find it useful. Maybe they won't want it! It's experimental :)

charliermarsh commented on Code formatting comes to uv experimentally pydevtools.com/blog/uv-fo... · Posted by u/tanelpoder

thanhhaimai · 2 days ago

I'd rather `ruff` being merged with `ty` instead. `uv` for me is about package / project manager. It's not about code style. The only time `uv` should edit a code file is to update its dependencies (PEP 723).

On the other hand, both `ruff` and `ty` are about code style. They both edit the code, either to format or fix typing / lint issues. They are good candidates to be merged.

charliermarsh · 2 days ago

To clarify, `ruff` and `uv` aren't being merged. They remain separate tools. This is more about providing a simpler experience for users that don't want to think about their formatter as a separate tool.

The analogy would be to Cargo: `cargo fmt` just runs `rustfmt`, but you can also run `rustfmt` separately if you want.

charliermarsh commented on PYX: The next step in Python packaging astral.sh/blog/introducin... · Posted by u/the_mitsuhiko

m4r71n · 11 days ago

What does GPU-aware mean in terms of a registry? Will `uv` inspect my local GPU spec and decide what the best set of packages would be to pull from Pyx?

Since this is a private, paid-for registry aimed at corporate clients, will there be an option to expose those registries externally as a public instance, but paid for by the company? That is, can I as a vendor pay for a Pyx registry for my own set of packages, and then provide that registry as an entrypoint for my customers?

charliermarsh · 10 days ago

> Will `uv` inspect my local GPU spec and decide what the best set of packages would be to pull from Pyx?

We actually support this basic idea today, even without pyx. You can run (e.g.) `uv pip install --torch-backend=auto torch` to automatically install a version of PyTorch based on your machine's GPU from the PyTorch index.

pyx takes that idea and pushes it further. Instead of "just" supporting PyTorch, the registry has a curated index for each supported hardware accelerator, and we populate that index with pre-built artifacts across a wide range of packages, versions, Python versions, PyTorch versions, etc., all with consistent and coherent metadata.

So there are two parts to it: (1) when you point to pyx, it becomes much easier to get the right, pre-built, mutually compatible versions of these things (and faster to install them); and (2) the uv client can point you to the "right" pyx index automatically (that part works regardless of whether you're using pyx, it's just more limited).

> Since this is a private, paid-for registry aimed at corporate clients, will there be an option to expose those registries externally as a public instance, but paid for by the company? That is, can I as a vendor pay for a Pyx registry for my own set of packages, and then provide that registry as an entrypoint for my customers?

We don't support this yet but it's come up a few times with users. If you're interested in it concretely feel free to email me (charlie@).

charliermarsh commented on I'm switching to Python and actually liking it cesarsotovalero.net/blog/... · Posted by u/cesarsotovalero

CoolCold · a month ago

> things like virtual envs

I consider my point as still valid with UV, what you wanted to express?

On UV specifically - say 'asdf' compiles python right on your system from official sources - means using your ssl libs for example. UV brings Python binary - I feel worried on this.

charliermarsh · a month ago

uv works just as well with whatever Python you want to bring -- you're not required to use the Pythons that uv is capable of installing on your machine.