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

Refactor applicability to use safe and unsafe #7819

Closed
wants to merge 1 commit into from

Conversation

zanieb
Copy link
Member

@zanieb zanieb commented Oct 4, 2023

Following much discussion for #4181 at #5119, #5476, #7769, and in Discord, this pull request changes Applicability from using Suggested for uncertain fixes to Unsafe.

Also removes Applicability::Unspecified (replacing #7792).

I have some qualms about how we will explain "manual" fixes to users which are a type of unsafe fix that cannot be applied programmatically. However, since manual fixes are not presented to the user after #7769 we can worry about this in the future.

@zanieb zanieb force-pushed the zanie/app-refactor-safe branch 2 times, most recently from 63d56d6 to b3f5bba Compare October 4, 2023 19:10
@zanieb zanieb added the internal An internal refactor or improvement label Oct 4, 2023
@zanieb
Copy link
Member Author

zanieb commented Oct 4, 2023

Here we structure applicability as two enumerations

  • Automatic
    • Safe
    • Unsafe
  • Manual

We could also consider a flat structure

  • Safe
  • Unsafe
  • Hint / Suggestion / Manual / Display / etc.

or a structure that more closely matches when it is applicable / safe

  • Always
  • Sometimes
  • Never

(implemented in #7821)

@codspeed-hq
Copy link

codspeed-hq bot commented Oct 4, 2023

CodSpeed Performance Report

Merging #7819 will degrade performances by 3.35%

Comparing zanie/app-refactor-safe (c5ae2f1) with main (59c00b5)

Summary

❌ 1 regressions
✅ 24 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

Benchmark main zanie/app-refactor-safe Change
linter/default-rules[large/dataset.py] 92.6 ms 95.8 ms -3.35%

@github-actions
Copy link
Contributor

github-actions bot commented Oct 4, 2023

PR Check Results

Ecosystem

✅ ecosystem check detected no changes.

@zanieb
Copy link
Member Author

zanieb commented Oct 5, 2023

Closing in favor of #7821

zanieb added a commit that referenced this pull request Oct 5, 2023
Following much discussion for #4181 at
#5119,
#5476, #7769,
#7819, and in
[Discord](https://discord.com/channels/1039017663004942429/1082324250112823306/1159144114231709746),
this pull request changes `Applicability` from using `Automatic`,
`Suggested`, and `Manual` to `Always`, `Sometimes`, and `Never`.

Also removes `Applicability::Unspecified` (replacing #7792).
zanieb added a commit that referenced this pull request Oct 7, 2023
After working with the previous change in
#7821 I found the names a bit
unclear and their relationship with the user-facing API muddied. Since
the applicability is exposed to the user directly in our JSON output, I
think it's important that these names align with our configuration
options. I've replaced `Manual` or `Never` with `Display` which captures
our intent for these fixes (only for display). Here, we create room for
future levels, such as `HasPlaceholders`, which wouldn't fit into the
`Always`/`Sometimes`/`Never` levels.

Unlike #7819, this retains the
flat enum structure which is easier to work with.
konstin pushed a commit that referenced this pull request Oct 11, 2023
Following much discussion for #4181 at
#5119,
#5476, #7769,
#7819, and in
[Discord](https://discord.com/channels/1039017663004942429/1082324250112823306/1159144114231709746),
this pull request changes `Applicability` from using `Automatic`,
`Suggested`, and `Manual` to `Always`, `Sometimes`, and `Never`.

Also removes `Applicability::Unspecified` (replacing #7792).
konstin pushed a commit that referenced this pull request Oct 11, 2023
After working with the previous change in
#7821 I found the names a bit
unclear and their relationship with the user-facing API muddied. Since
the applicability is exposed to the user directly in our JSON output, I
think it's important that these names align with our configuration
options. I've replaced `Manual` or `Never` with `Display` which captures
our intent for these fixes (only for display). Here, we create room for
future levels, such as `HasPlaceholders`, which wouldn't fit into the
`Always`/`Sometimes`/`Never` levels.

Unlike #7819, this retains the
flat enum structure which is easier to work with.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal An internal refactor or improvement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant