Idea: A project analyzer/detective module to be used as a FawltyDeps frontend

[jherland]

In relation to our ongoing experiment where we analyze popular PyPI experiment, I've been thinking about what the eventual fallout from this could be, in terms of new FawltyDeps features/improvements.

One thing we're looking to do is to get better at detecting what kind of project we're looking at, and automatically tuning the behavior of FD accordingly:

• E.g. in a project that uses pip-tools to pip compile a requirements.in file into a requirements.txt file, we would want FD to only look at the requirements.in file by default (i.e. --deps=requirements.in)
• We would want FD to be smarter about where the code in a projects is located, e.g. make it possible to skip test code, etc.
• As demonstrated by issues like Support for Django apps which are used in project but not directly imported #373, we would like FD to detect other aspects of the project that should affect its behavior.

If we try to bake these detectors/behavioral adjustments into FD itself, it will likely complicate the internal logic considerably, and make FD less maintainable over time. Instead, I propose a separate module/package for project detection whose sole purpose is to look at a Python project and come up with the appropriate settings for FawltyDeps to use by default.

This could be run as a one-off thing, e.g. you run fawltydeps-detect >> pyproject.toml to produce a TOML config section for FawltyDeps to use later, or it could be something that is run by FD as an initial phase of the analysis. It could even be structured as a wizard that asks the user relevant questions (if necessary).

The main idea is that this component:

• is separately testable
• has a clear and unambiguous interface to the rest of FD, namely the FD settings object.
• collects logic about a wide variety of Python project types, so that FD can remain relatively agnostic and ignorant of these details.