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.

Sign up for GitHub

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

Jump to bottom

[red-knot] Persistent configuration #15491

Open
6 of 15 tasks
MichaReiser opened this issue Jan 15, 2025 · 2 comments
Open
6 of 15 tasks

[red-knot] Persistent configuration #15491

MichaReiser opened this issue Jan 15, 2025 · 2 comments
Assignees
@MichaReiser
Labels
red-knot Multi-file analysis & type inference
Milestone
Red Knot Q1 2025

Comments

@MichaReiser
Copy link
Member

MichaReiser commented Jan 15, 2025 •
edited
Loading

Support configuring Red Knot in a persistent configuration:

  • Configuration in the project's pyproject.toml or knot.toml.
  • Configuration sections:
    • rules: enable and disable rules
    • environment: (python version, platform, search paths)
    • files: Override a sub-set of settings on a path level
    • src: Which files should be considered first-party and what's the src root
    • terminal: Configure color output, etc.
    • root options (for now, only respect-ignore-files)
    • requires-python (I'm leaning towards just making it a field on ProjectMetadata because we only respect the requires-python constraint in the project's configuration file)
  • Path anchoring in configuration files (relative paths are relative to the current working directory, the configuration file, or the project root)
  • Track the source of a configuration value for better error reporting: E.g. clippy tells you why a rule is enabled. Is it because the rule is enabled by default or because you enabled it in the configuration or in the CLI? Ideally, we'd have this for all options so that we can refer users to the right configuration file if we detect an invalid setting.
  • User-level configuration
  • Support overriding configuration options from the CLI
  • Hierarchical configuration (knot.toml in any ancestor directory)
  • Generate a JSON schema
@MichaReiser MichaReiser added the red-knot Multi-file analysis & type inference label Jan 15, 2025
@MichaReiser MichaReiser added this to the Red Knot Q1 2025 milestone Jan 15, 2025
@MichaReiser MichaReiser self-assigned this Jan 15, 2025
MichaReiser added a commit that referenced this issue Jan 15, 2025
@MichaReiser
Add support for configuring knot in pyproject.toml files
17e209e 
This PR adds support for configuring Red Knot in the `tool.knot` section of the project's
`pyproject.toml` section. Options specified on the CLI take precedence over the
options in the configuration file.

For now, this PR only adds support for the `environment` and the `src.root` options.
Other options will be added as separate PRs.

There are also a few concerns that I intentionally ignored as part of this PR:

* Handling of relative paths: We need to anchor paths relative to the current working directory (CLI), or the project (`pyproject.toml` or `knot.toml`)
* Tracking the source of a value. It would be nice for diagnostics to know from which configuration a value comes so that we can point the user to the right configuration file (or CLI) if the configuration is invalid.
* Schema generation, and there's a lot more, see #15491
@MichaReiser MichaReiser mentioned this issue Jan 15, 2025
Merged
MichaReiser added a commit that referenced this issue Jan 15, 2025
@MichaReiser
Add support for configuring knot in pyproject.toml files
6487e53 
This PR adds support for configuring Red Knot in the `tool.knot` section of the project's
`pyproject.toml` section. Options specified on the CLI take precedence over the
options in the configuration file.

For now, this PR only adds support for the `environment` and the `src.root` options.
Other options will be added as separate PRs.

There are also a few concerns that I intentionally ignored as part of this PR:

* Handling of relative paths: We need to anchor paths relative to the current working directory (CLI), or the project (`pyproject.toml` or `knot.toml`)
* Tracking the source of a value. It would be nice for diagnostics to know from which configuration a value comes so that we can point the user to the right configuration file (or CLI) if the configuration is invalid.
* Schema generation, and there's a lot more, see #15491
MichaReiser added a commit that referenced this issue Jan 15, 2025
@MichaReiser
Add support for configuring knot in pyproject.toml files
93875ec 
This PR adds support for configuring Red Knot in the `tool.knot` section of the project's
`pyproject.toml` section. Options specified on the CLI take precedence over the
options in the configuration file.

For now, this PR only adds support for the `environment` and the `src.root` options.
Other options will be added as separate PRs.

There are also a few concerns that I intentionally ignored as part of this PR:

* Handling of relative paths: We need to anchor paths relative to the current working directory (CLI), or the project (`pyproject.toml` or `knot.toml`)
* Tracking the source of a value. It would be nice for diagnostics to know from which configuration a value comes so that we can point the user to the right configuration file (or CLI) if the configuration is invalid.
* Schema generation, and there's a lot more, see #15491
MichaReiser added a commit that referenced this issue Jan 15, 2025
@MichaReiser
Add support for configuring knot in pyproject.toml files
f207805 
This PR adds support for configuring Red Knot in the `tool.knot` section of the project's
`pyproject.toml` section. Options specified on the CLI take precedence over the
options in the configuration file.

For now, this PR only adds support for the `environment` and the `src.root` options.
Other options will be added as separate PRs.

There are also a few concerns that I intentionally ignored as part of this PR:

* Handling of relative paths: We need to anchor paths relative to the current working directory (CLI), or the project (`pyproject.toml` or `knot.toml`)
* Tracking the source of a value. It would be nice for diagnostics to know from which configuration a value comes so that we can point the user to the right configuration file (or CLI) if the configuration is invalid.
* Schema generation, and there's a lot more, see #15491
@MichaReiser MichaReiser mentioned this issue Jan 15, 2025
Merged
MichaReiser added a commit that referenced this issue Jan 16, 2025
@MichaReiser
Add support for configuring knot in pyproject.toml files
be6b356 
This PR adds support for configuring Red Knot in the `tool.knot` section of the project's
`pyproject.toml` section. Options specified on the CLI take precedence over the
options in the configuration file.

For now, this PR only adds support for the `environment` and the `src.root` options.
Other options will be added as separate PRs.

There are also a few concerns that I intentionally ignored as part of this PR:

* Handling of relative paths: We need to anchor paths relative to the current working directory (CLI), or the project (`pyproject.toml` or `knot.toml`)
* Tracking the source of a value. It would be nice for diagnostics to know from which configuration a value comes so that we can point the user to the right configuration file (or CLI) if the configuration is invalid.
* Schema generation, and there's a lot more, see #15491
MichaReiser added a commit that referenced this issue Jan 16, 2025
@MichaReiser
Add support for configuring knot in pyproject.toml files
c8a8a01 
This PR adds support for configuring Red Knot in the `tool.knot` section of the project's
`pyproject.toml` section. Options specified on the CLI take precedence over the
options in the configuration file.

For now, this PR only adds support for the `environment` and the `src.root` options.
Other options will be added as separate PRs.

There are also a few concerns that I intentionally ignored as part of this PR:

* Handling of relative paths: We need to anchor paths relative to the current working directory (CLI), or the project (`pyproject.toml` or `knot.toml`)
* Tracking the source of a value. It would be nice for diagnostics to know from which configuration a value comes so that we can point the user to the right configuration file (or CLI) if the configuration is invalid.
* Schema generation, and there's a lot more, see #15491
MichaReiser added a commit that referenced this issue Jan 16, 2025
@MichaReiser
Add support for configuring knot in pyproject.toml files
b485a63 
This PR adds support for configuring Red Knot in the `tool.knot` section of the project's
`pyproject.toml` section. Options specified on the CLI take precedence over the
options in the configuration file.

For now, this PR only adds support for the `environment` and the `src.root` options.
Other options will be added as separate PRs.

There are also a few concerns that I intentionally ignored as part of this PR:

* Handling of relative paths: We need to anchor paths relative to the current working directory (CLI), or the project (`pyproject.toml` or `knot.toml`)
* Tracking the source of a value. It would be nice for diagnostics to know from which configuration a value comes so that we can point the user to the right configuration file (or CLI) if the configuration is invalid.
* Schema generation, and there's a lot more, see #15491
MichaReiser added a commit that referenced this issue Jan 17, 2025
@MichaReiser
Add support for configuring knot in pyproject.toml files (#15493)
eb47a66 
## Summary

This PR adds support for configuring Red Knot in the `tool.knot` section
of the project's
`pyproject.toml` section. Options specified on the CLI precede the
options in the configuration file.

This PR only supports the `environment` and the `src.root` options for
now.
Other options will be added as separate PRs.

There are also a few concerns that I intentionally ignored as part of
this PR:

* Handling of relative paths: We need to anchor paths relative to the
current working directory (CLI), or the project (`pyproject.toml` or
`knot.toml`)
* Tracking the source of a value. Diagnostics would benefit from knowing
from which configuration a value comes so that we can point the user to
the right configuration file (or CLI) if the configuration is invalid.
* Schema generation and there's a lot more; see
#15491

This PR changes the default for first party codes: Our existing default
was to only add the project root. Now, Red Knot adds the project root
and `src` (if such a directory exists).

Theoretically, we'd have to add a file watcher event that changes the
first-party search paths if a user later creates a `src` directory. I
think this is pretty uncommon, which is why I ignored the complexity for
now but I can be persuaded to handle it if it's considered important.

Part of #15491

## Test Plan

Existing tests, new file watching test demonstrating that changing the
python version and platform is correctly reflected.
@hauntsaninja
Copy link
Contributor

hauntsaninja commented Jan 21, 2025 •
edited
Loading

Note mypy has gotten some use of being able to configure things on a module level, not path level. In particular, this works well for settings related to specific dependencies (e.g. ignoring them or ignoring their possible non-existence or ignoring PEP 561 warnings or setting implicit export behaviour etc etc)

@MichaReiser
Copy link
Member Author

Interesting. Overall, we don't plan on emitting warnings for third-party code (we don't check third party code). Allowing non-existent modules is its own setting that only takes module names and the same is probably true for PEP 561. I'd have to look into implicit export behavior more closely.

This was referenced Jan 22, 2025
Merged
Merged
Merged
@MichaReiser MichaReiser mentioned this issue Feb 3, 2025
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@MichaReiser MichaReiser

Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Milestone
Red Knot Q1 2025
Development

No branches or pull requests
2 participants
@MichaReiser @hauntsaninja