8 ms·

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 co

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.

WD-42 1y ago
They are mimicking Rust's cargo, which has `cargo fmt`
- munificent 1y ago
  Also `go fmt` and `dart format`.
- Biganon 1y ago
  > They are mimicking Rust's cargo Cargo cargo cult?
  - xdennis 1y ago
    It's not a cargo cult if it actually works.
- petcat 1y ago
  Doesn't cargo just have a subcommand plugin system? Or is fmt actually hard-coded into the cargo code? I prefer the plugin system. I don't like god programs like what the npm monstrosity became.
  - woodruffw 1y ago
    cargo has an external subcommand system, but it also has "blessed" (my word choice) external subcommands that are typically bootstrapped via Rust toolchain components. This makes them pretty analogous to what uv does here with `uv format`, in my opinion.
munro 1y ago
But what if `ty` was also eventually merged into `uv` as well? 8-) That's probably the vision, given all from astral.sh, but `ty` isn't ready yet.
zahlman 1y ago
This is the direction I expected things to go, and not something I'm especially fond of. I'll stick with UNIX-philosophy tools, thanks.
- zem 1y ago
  this is very much in line with the unix philosophy - it delegates formatting to ruff and simply provides a unified front end that calls out to the right specialized tool. think of it as a makefile.
  - zahlman 1y ago
    I don't think this is an apt (pun intended?) comparison at all.
    - d0mine 1y ago
      One can find repos using `make format` / `make lint`/ `make typecheck` / or similar I remember David Beazley mentioning that code with Makefiles were relatively easier to analyze based on ~Terabyte of C++ code and no internet connection (pycon 2014) https://youtube.com/watch?v=RZ4Sn-Y7AP8 https://youtube.com/watch?v=RZ4Sn-Y7AP8
      - Kwpolska 1y ago
        That `make format` command was not defined by the Make developers, but by the team using Make in their project. They picked their favorite formatter and defined a shortcut. In this case, the uv developers are forcing the command on everyone, and they're using it to cross-promote their own formatting tool.
        Hendrikto 1y ago
        They are not forcing anything on anyone. You can decide to never run `uv format` and ruff won’t even be installed. You can use uv without ruff. You can use ruff without uv. You can invoke ruff yourself if that’s what you want. Or use any other formatter. I don’t think I understand what your complaint is.
impulser_ 1y ago
I think the goal is to make uv a complete package manager for Python while still giving you the option to use the parts separately. uv is like cargo for python. If you only need a fast type checker you can just use ty, if you just need a fast formatter and linter you can just use ruff. Combining ruff and ty doesn't make sense if you think about like this.
- RossBencina 1y ago
  Including a formatter in a package manager doesn't make sense to me. Seems like obvious feature creep. My understanding was that uv is for installing dependencies (e.g. like pip) with the added benefit of also installing/managing python interpreters (which can be reasonably thought of as a dependency). This makes sense. Adding more stuff doesn't make sense.
  - masklinn 1y ago
    GP should have written project manager not package. Think npm / go / cargo, not apt/yum/pip.
    - Kwpolska 1y ago
      Doesn't make it less feature creep.
      - masklinn 1y ago
        I’m sure you’re a old man on the verge of death who loves yelling at clouds but enforcement and application of consistent code formatting has been considered a basic part of project management for a while now. Recent langage provide it as part of core project management tooling. Given uv is openly strongly inspired by cargo and astral also has tooling for code formatting, the integration was never a question of “if”.
        zelphirkalt 1y ago
        I remember how in a previous job the code formatter cost me time and time again. I already intentionally format my code as it makes sense and with the goal of improving readability. Then the damn auto formatter comes along and destroys this, by splitting a log call over 5 lines, because it has seen, that the log call is longer than 80 characters. Thank you for wasting 5 LoC of screen space for something that is a sidenote basically. That'll surely improve readability. So what do people do? They increase line length to 200 characters, to avoid this shit happening. Only that now it does no longer break long lines that should be broken. Unless I added trailing comma everywhere, wasting more time to make the formatter behave properly. I am not against auto formatters in general, but they need to be flexible and semantically aware. A log call is not the same as other calls in significance. If the auto formatter is too silly to do that, then I prefer no auto formatter at all and keep my code well formatted myself, which I do anyway while I am writing the code. I do it for my own sake and for anyone who comes along later. My formatting is already pretty much standard.
charliermarsh 1y 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.
- WD-42 1y ago
  Thank you for writing software for all of us Python day-jobbers who wish we were writing Rust instead.
  - weakfish 1y ago
    Never seen someone put my feeling so succinctly
  - echelon 1y ago
    You can advocate for using Rust at work. If you're writing microservices, the Rust ecosystem sells itself at this point.
    - foxygen 1y ago
      What Rust has over other languages that makes it better for writing microservices?
      - mtndew4brkfst 1y ago
        API-first or API-only backends are a sweet spot for today's Rust, IMO, and its resource footprint, reduced maintenance long-tail, and performance properties are all super competitive. It's especially hard to find another language that can compete with Rust on all three of those at once.
        simpaticoder 1y ago
        >reduced maintenance long-tail I'd like to hear more about that. I'm also curious what makes Rust particularly suited to "API-first" backends. My understanding of the language is that it's concurrency primitives are excellent but difficult to learn and it's gc-less runtime.
alfalfasprout 1y ago
Oh please no... The reality is, ecosystems evolve. First, we had mypy. Then more type checkers came out: pyre, pyright, etc. Then basedpyright. The era of rust arrived and now we have `ty` and `pyrefly` being worked on heavily. On the linter side we saw flake8, black, and then ruff. Decoupling makes adapting to evolution much easier. As long as both continue to offer LSP integrations it allows engineers to pick and chose what's best.
- d0mine 1y ago
  The whole premise of uv that you don't need to know that you can install specific python version using eg pyenv (`uv python install` or `uv run` may do it implicitly), you don't need to know about `python -m venv`/virtualenv (`uv venv`), or how to create lock files pip-tools / pipenv / poetry / etc(`uv lock`), or pipx (`uv tool install`) or `pip install`/ `pipenv install`/`poetry add` / many others (`uv add`), or how to build artifacts setuptools / hatchling / poetry way / etc (`uv build`). Other commands such as `uv sync` didn't break new ground too. `uv format` is similar (you don't need to know about `ruff format` / black / yapf ).
  - Kwpolska 1y ago
    All actions listed in your first paragraph, except for installing specific Python versions, are actions related to the area of packaging. Doing it in one tool is completely sensible. I'm not a fan of uv managing Pythons, but I guess that ship has sailed. But formatting code is a completely new area that does not fit uv.
darkamaul 1y ago
And I would think the next logical step here is to have a `uv lint` option here that runs ˋty` under the hood ? I would love to see a world where there is a single or a set of standard commands that would prepare your python project (format, lint, test, publish). Maybe that’s the vision here?

WD-42 1y ago

They are mimicking Rust's cargo, which has `cargo fmt`

munificent 1y ago
Also `go fmt` and `dart format`.
Biganon 1y ago
> They are mimicking Rust's cargo Cargo cargo cult?
- xdennis 1y ago
  It's not a cargo cult if it actually works.
petcat 1y ago
Doesn't cargo just have a subcommand plugin system? Or is fmt actually hard-coded into the cargo code? I prefer the plugin system. I don't like god programs like what the npm monstrosity became.
- woodruffw 1y ago
  cargo has an external subcommand system, but it also has "blessed" (my word choice) external subcommands that are typically bootstrapped via Rust toolchain components. This makes them pretty analogous to what uv does here with `uv format`, in my opinion.

munro 1y ago

But what if `ty` was also eventually merged into `uv` as well? 8-) That's probably the vision, given all from astral.sh, but `ty` isn't ready yet.

zahlman 1y ago

This is the direction I expected things to go, and not something I'm especially fond of. I'll stick with UNIX-philosophy tools, thanks.

zem 1y ago
this is very much in line with the unix philosophy - it delegates formatting to ruff and simply provides a unified front end that calls out to the right specialized tool. think of it as a makefile.
- zahlman 1y ago
  I don't think this is an apt (pun intended?) comparison at all.
  - d0mine 1y ago
    One can find repos using `make format` / `make lint`/ `make typecheck` / or similar I remember David Beazley mentioning that code with Makefiles were relatively easier to analyze based on ~Terabyte of C++ code and no internet connection (pycon 2014) https://youtube.com/watch?v=RZ4Sn-Y7AP8 https://youtube.com/watch?v=RZ4Sn-Y7AP8
    - Kwpolska 1y ago
      That `make format` command was not defined by the Make developers, but by the team using Make in their project. They picked their favorite formatter and defined a shortcut. In this case, the uv developers are forcing the command on everyone, and they're using it to cross-promote their own formatting tool.
      - Hendrikto 1y ago
        They are not forcing anything on anyone. You can decide to never run `uv format` and ruff won’t even be installed. You can use uv without ruff. You can use ruff without uv. You can invoke ruff yourself if that’s what you want. Or use any other formatter. I don’t think I understand what your complaint is.

impulser_ 1y ago

I think the goal is to make uv a complete package manager for Python while still giving you the option to use the parts separately. uv is like cargo for python. If you only need a fast type checker you can just use ty, if you just need a fast formatter and linter you can just use ruff. Combining ruff and ty doesn't make sense if you think about like this.

RossBencina 1y ago
Including a formatter in a package manager doesn't make sense to me. Seems like obvious feature creep. My understanding was that uv is for installing dependencies (e.g. like pip) with the added benefit of also installing/managing python interpreters (which can be reasonably thought of as a dependency). This makes sense. Adding more stuff doesn't make sense.
- masklinn 1y ago
  GP should have written project manager not package. Think npm / go / cargo, not apt/yum/pip.
  - Kwpolska 1y ago
    Doesn't make it less feature creep.
    - masklinn 1y ago
      I’m sure you’re a old man on the verge of death who loves yelling at clouds but enforcement and application of consistent code formatting has been considered a basic part of project management for a while now. Recent langage provide it as part of core project management tooling. Given uv is openly strongly inspired by cargo and astral also has tooling for code formatting, the integration was never a question of “if”.
      - zelphirkalt 1y ago
        I remember how in a previous job the code formatter cost me time and time again. I already intentionally format my code as it makes sense and with the goal of improving readability. Then the damn auto formatter comes along and destroys this, by splitting a log call over 5 lines, because it has seen, that the log call is longer than 80 characters. Thank you for wasting 5 LoC of screen space for something that is a sidenote basically. That'll surely improve readability. So what do people do? They increase line length to 200 characters, to avoid this shit happening. Only that now it does no longer break long lines that should be broken. Unless I added trailing comma everywhere, wasting more time to make the formatter behave properly. I am not against auto formatters in general, but they need to be flexible and semantically aware. A log call is not the same as other calls in significance. If the auto formatter is too silly to do that, then I prefer no auto formatter at all and keep my code well formatted myself, which I do anyway while I am writing the code. I do it for my own sake and for anyone who comes along later. My formatting is already pretty much standard.

charliermarsh 1y 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.

WD-42 1y ago
Thank you for writing software for all of us Python day-jobbers who wish we were writing Rust instead.
- weakfish 1y ago
  Never seen someone put my feeling so succinctly
- echelon 1y ago
  You can advocate for using Rust at work. If you're writing microservices, the Rust ecosystem sells itself at this point.
  - foxygen 1y ago
    What Rust has over other languages that makes it better for writing microservices?
    - mtndew4brkfst 1y ago
      API-first or API-only backends are a sweet spot for today's Rust, IMO, and its resource footprint, reduced maintenance long-tail, and performance properties are all super competitive. It's especially hard to find another language that can compete with Rust on all three of those at once.
      - simpaticoder 1y ago
        >reduced maintenance long-tail I'd like to hear more about that. I'm also curious what makes Rust particularly suited to "API-first" backends. My understanding of the language is that it's concurrency primitives are excellent but difficult to learn and it's gc-less runtime.

alfalfasprout 1y ago

Oh please no... The reality is, ecosystems evolve. First, we had mypy. Then more type checkers came out: pyre, pyright, etc. Then basedpyright. The era of rust arrived and now we have `ty` and `pyrefly` being worked on heavily. On the linter side we saw flake8, black, and then ruff. Decoupling makes adapting to evolution much easier. As long as both continue to offer LSP integrations it allows engineers to pick and chose what's best.

d0mine 1y ago
The whole premise of uv that you don't need to know that you can install specific python version using eg pyenv (`uv python install` or `uv run` may do it implicitly), you don't need to know about `python -m venv`/virtualenv (`uv venv`), or how to create lock files pip-tools / pipenv / poetry / etc(`uv lock`), or pipx (`uv tool install`) or `pip install`/ `pipenv install`/`poetry add` / many others (`uv add`), or how to build artifacts setuptools / hatchling / poetry way / etc (`uv build`). Other commands such as `uv sync` didn't break new ground too. `uv format` is similar (you don't need to know about `ruff format` / black / yapf ).
- Kwpolska 1y ago
  All actions listed in your first paragraph, except for installing specific Python versions, are actions related to the area of packaging. Doing it in one tool is completely sensible. I'm not a fan of uv managing Pythons, but I guess that ship has sailed. But formatting code is a completely new area that does not fit uv.

darkamaul 1y ago

And I would think the next logical step here is to have a `uv lint` option here that runs ˋty` under the hood ? I would love to see a world where there is a single or a set of standard commands that would prepare your python project (format, lint, test, publish). Maybe that’s the vision here?