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

Auto fix #393

Open
GuillaumeDesforges opened this issue Nov 9, 2023 · 2 comments
Open

Auto fix #393

GuillaumeDesforges opened this issue Nov 9, 2023 · 2 comments

Comments

@GuillaumeDesforges
Copy link

Is your feature request related to a problem? Please describe.
I'd rather not think too much and have it automatically add missing deps.

Describe the solution you'd like
Other tools, e.g. ruff, provide a --fix flag.
I would think having a --fix flag would then do the scanning, detect how I declare my deps, add do what is necessary to add/remove missing or unnecessary deps.
Ofc any failuyre would then be reported so I can do the more complex stuff myself.

Describe alternatives you've considered
Doing it manually.

Additional context
As a first step, printing bash commands I could copy/paste/run would already be a nice improvement (I use poetry).

@GuillaumeDesforges GuillaumeDesforges changed the title Auto fix issues Auto fix Nov 9, 2023
@jherland
Copy link
Member

jherland commented Nov 14, 2023

This is a very big ask with lots of caveats and complexities.

For tools like ruff, black, isort, pylint, etc. there is typically a fairly clear plan that allows for things to be auto-fixed: E.g. 'black' has decided what the formatting of Python code should be, and by using it you implicitly agree with its decisions. For 'isort', there is similary an agreed convention (PEP 8, I think) on how imports should be sorted. For linters, too, there are sometimes straightforward fixes, but you only need to search for "fix" on ruff's configuration page to realize that there are complexities even for fixing linter errors.

What FawltyDeps is tackling is different, in that there is often not one clear course of action:

  • Given an undeclared dependency found by FawltyDeps:
    • Do we remove the import statement from the code (probably not in most cases, but we cannot be sure)
    • Do we add a declaration for this dependency?
      • What package do we add? What if there are more packages that provide the same import name?
      • What version of the package do we depend on?
      • Do we add it as a main dependency, or as an extra dependency?
    • (Did FawltyDeps correctly identify an undeclared dependency?)
  • Given an unused dependency found by FalwtyDeps:
    • Do we simply remove the dependency declaration?
    • Sometimes the right solution is in fact to add code to use the dependency, and/or add an exception with --ignore-unused (e.g. for tools that we don't recognize)

If we assume that the above questions can be answered conclusively in a large enough proportion of cases to actually be useful, then comes the next challenge: how/where to we apply the fix?

We might limit ourselves to say that we can only make fixes in dependency declarations (not in Python code), but even then, the formats are not always easy to edit:

  • setup.py can both declare dependencies and also Python code of arbitrary complexity (this is already a problem we have when parsing dependency declarations).
  • pyproject.toml has different dependency fields depending on whether you use Poetry or a PEP621-compliant tool.
  • You could have multiple files with dependency declarations
    • in some cases (e.g. requirments.in + requirements.txt) it is easy to decide which file to edit,
    • but in other cases it's impossible (requirements.txt + dev-requirements.txt?)

At the very least, this issue depends in large part on something like #375 just to figure out how/where to apply any potential fixes.

So my opinion for now, in summary: It is pretty much impossible for FawltyDeps to be able to fix dependency issues as well as something like black or ruff can fix formatting/linting. There might be some cases where we can do a good job, but whether or not those cases are large/common enough to warrant this addition is an open question. Also, it would take a lot of work to get there...

@jherland
Copy link
Member

jherland commented Nov 14, 2023

(Sorry, fat-fingered the close button in the middle of writing my comment...)

@jherland jherland reopened this Nov 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants