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

feature request: flake8-future-annotations #1767

Closed
danieleades opened this issue Jan 10, 2023 · 6 comments
Closed

feature request: flake8-future-annotations #1767

danieleades opened this issue Jan 10, 2023 · 6 comments
Labels
plugin Implementing a known but unsupported plugin

Comments

@danieleades
Copy link

see https://pypi.org/project/flake8-future-annotations/

@charliermarsh
Copy link
Member

Will #1762 resolve this? (Supporting isort's add-imports setting?)

@charliermarsh charliermarsh added the plugin Implementing a known but unsupported plugin label Jan 10, 2023
@charliermarsh
Copy link
Member

If so, that should go out today :)

@danieleades
Copy link
Author

Not exactly. That feature will just insert the import indiscriminately in every file, whereas the plugin will (by default) only insert them where they would do something.
It's a subtle distinction, maybe not worth worrying about

@danieleades
Copy link
Author

These kinds of overlaps in functionality beg the question- what does the future of ruff look like? Right now it's aiming at being a drop-in replacement for existing tools, along with their various quirks and configuration.
Is there going to be a ruff V2 that drops this legacy interface and prioritises self-consistency? What does that look like?
Not related to this feature, just curious

@charliermarsh
Copy link
Member

Yeah I think for now, I'm gonna run with the add-imports approach. I like that it generalizes to other __future__ imports (and other imports more broadly), and in doing some Code Search, it seems relatively popular. So I'm going to mark as closed for now by #1762.

@charliermarsh
Copy link
Member

These kinds of overlaps in functionality beg the question- what does the future of ruff look like? Right now it's aiming at being a drop-in replacement for existing tools, along with their various quirks and configuration. Is there going to be a ruff V2 that drops this legacy interface and prioritises self-consistency? What does that look like? Not related to this feature, just curious

Yes! @not-my-profile actually just created some issues that'll help move us in that direction (#1773, #1774).

To lay out my current thinking (still early):

  • I'd like to move to a world in which we have our own categorization and lint rule names. If your project is fully on Ruff, it doesn't really make sense to think in terms of Flake8 plugins. And Ruff, ideally, wouldn't be bound by Flake8 conventions.
  • That said, compatibility with Flake8 is extremely helpful for adoption, and I don't want to give that up yet. So I'd like to continue to support the Flake8-style interface, and maintain the mapping from Flake8 plugins + rules to Ruff rules.
  • I'm hoping that, since this is all happening within Ruff, we can provide tooling to automatically upgrade your codebase from Flake8 compatibility mode to first-class-Ruff mode. This would involve rewriting your pyproject.toml, and changing your action comments (# noqa, # isort: skip, etc.). So in theory, if you're fully on Ruff, we should be able to make it pretty easy to "upgrade".
  • Eventually, it could be the case that we no longer support the Flake8 compatibility mode; or even, that the Flake8 compatibility mode continues to exist, but internally, we're just remapping your configuration to the first-class-Ruff version (whatever that looks like at runtime).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plugin Implementing a known but unsupported plugin
Projects
None yet
Development

No branches or pull requests

2 participants