Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ruff format out of place? #9720

Closed
suo opened this issue Jan 30, 2024 · 3 comments
Closed

ruff format out of place? #9720

suo opened this issue Jan 30, 2024 · 3 comments
Labels
formatter Related to the formatter wish Not on the current roadmap; maybe in the future

Comments

@suo
Copy link

suo commented Jan 30, 2024

The default behavior of ruff format is to do an in-place rewrite of the provided files. If you pass source code in via stdin, ruff will output the formatted source to stdout.

It would be great to have an option where we can pass multiple files into ruff format, and get a structured response back with formatted sources for each of the files, somewhat analogous to ruff --output-format=json <files>.

This would be helpful for a project like ours (PyTorch) which calls out to ruff programmatically from various tools.

Happy to contribute this if folks are okay with it.

@zanieb
Copy link
Member

zanieb commented Jan 30, 2024

Thanks for the issue and offer to contribute :)

We're thinking about rewriting our LSP in Rust so it can be in ruff directly. I wonder if that would help with your use case? I think it'd provide an API like what you're looking for.

I'm not sure if different output formats make sense in the ruff format CLI. Curious what @MichaReiser thinks.

@zanieb zanieb added the formatter Related to the formatter label Jan 30, 2024
@MichaReiser MichaReiser added the wish Not on the current roadmap; maybe in the future label Jan 31, 2024
@MichaReiser
Copy link
Member

It's funny. I've just been talking with @charliermarsh about this because it would be nice if range formatting could return only the portion of the code that needs replacing together with the range that must be replaced rather than the entire file.

We concluded that it would be nice to have but will no longer be necessary once we've rewritten our LSP in Rust because it can then call the internal API directly. I also think that promoting the LSP as a programmatic Ruff API (until we have a Python API) has benefits:

  • It keeps the CLI API smaller and removes the need to maintain two programmatic APIs
  • The LSP is well-tested because it is used in IDEs
  • The LSP is a server, Ruff can cache state between calls, potentially making it faster than spawning the CLI for each file
  • There's an official specification (we don't need to come up with good APIs)

The main downside is that using it is more involved. For example, to format a file:

  • Start the LSP process
  • Send the initialize request
  • Send the open file request
  • Send the format request
  • Send the close file request (optional, but you may want Ruff to release some memory every now and then)
  • Send the shutdown request
  • Wait for the process to end

@MichaReiser
Copy link
Member

I'll close this in favor of #659, which asks for a Ruff API (not just formatting).

@MichaReiser MichaReiser closed this as not planned Won't fix, can't repro, duplicate, stale Feb 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
formatter Related to the formatter wish Not on the current roadmap; maybe in the future
Projects
None yet
Development

No branches or pull requests

3 participants