← Back to context

Comment by godelski

2 days ago

Is `uv format` supposed to be an alias for `ruff check`?

Stupidly I ran `uv format` without `--check` (no harm done and I can `git diff` it) so I didn't see the changes it made but `ruff check` does still show things that can be fixed with `ruff check --fix`. If I'm guessing correctly the difference is coming down to the fact that I have (in my submodule where all changes were made) a pyproject.toml file with ruff rules (there's also a .flake8 file. Repo is being converted). Either way, I find this a bit confusing userside. Not sure what to expect.

I think one thing I would like is that by default `uv format` spits out what files were changed like `uv format --check` does (s/Would reformat/Reformatted/g). Fine for the actual changes not to be displayed but I think this could help with error reduction. Running it again I can see it knows 68 files were changed. Where is that information being stored? It's pretty hard to grep out a number like that (`grep -R \<68\>`) and there's a lot of candidates (honestly there's nothing that looks like a good candidate).

Also, there's a `--quiet` flag, but the output is already pretty quiet. As far as I can tell the only difference is that quiet suppresses the warning (does `--quiet` also suppress errors?)

  uv format
  warning: `uv format` is experimental and may change without warning. Pass `--preview-features format` to disable this warning.
  36 files reformatted, 31 files left unchanged

  uv format --quiet
  36 files reformatted, 31 files left unchanged

I like the result for `--quiet` but I have a strong preference that `uv format` match the verbosity of `uv format --check`. I can always throw information away but not recover. I have a strong bias that it is better to fail by displaying too much information than fail by displaying too little. The latter failure mode is more harmful as the former is much more easily addressed by existing tools. If you're taking votes, that's mine.

Anyways, looking forward to seeing how this matures. Loved everything so far!

> Is `uv format` supposed to be an alias for `ruff check`?

I'd imagine not, since `ruff format` and `ruff check` are separate things too.

  • That makes some more sense. I think I just misunderstood what Charlie was saying above.

    But I'll also add another suggestion/ask. I think this could be improved

      $ ruff format --help
      Run the Ruff formatter on the given files or directories
      $ uv format --help
      Format Python code in the project
    

    I think just a little more can go a long way. When --help is the docs instead of man I think there needs to be a bit more description. Just something like this tells users a lot more

      $ ruff format --help
      Formats the specified files. Acts as a drop-in replacement for black. 
      $ uv format --help
      Experimental uv formatting. Alias to `ruff format`
    

    I think man/help pages are underappreciated. I know I'm not the only one that discovers new capabilities by reading them. Or even the double tab because I can't remember the flag name but see something I didn't notice before. Or maybe I did notice before but since the tool was new I focused on main features first. Having the ability to read enough information to figure out what these things do then and there really speeds up usage. When the help lines don't say much I often never explore them (unless there's some gut feeling). I know the browser exists, but when I'm using the tool I'm not in the browser.