feat: add mypy schema

[henryiii]

This adds a schema for mypy.

[hyperupcall]

Thanks! I was wondering your thoughts on using the name unstable-internal-mypy.json?

There seems to be a common use case for schemas that are their own file, and only meant to be referenced/$ref'd in another schema. But, we don't explicitly state it, with code, naming, or otherwise, so I'm thinking we can prefix the name of these schemas with unstable-internal-

I think that this name would make it more obvious that the schema is an internal abstraction, solely to make editing schemas in this repository easier. For example, when IDEs prompt a user to explicitly select a JSON schema to use, they can potentially ignore entries that match ^unstable-internal since they will never apply to a whole file (checking for an empty fileMatch is not semantically correct, and will lead to false negatives). I also think it would be useful for these entries to be "alphabetically besides each other" on file system explorers and also the "unstable" name will make it clear not to use it, in case further refactoring or name changes is needed on our part.

[hyperupcall]

(I saw your python/mypy#16601 PR, and I'm working on something similar with jsonschema-extractor, and I think deciding on an informal convention would be beneficial.)

[henryiii]

Unstable sounds like it should not be used. It's actually very useful on its own; I'm using them with validate-pyproject (PR merged, but unreleased so far), which expects the schema to describe the tool section. validate-pyproject --tool mypy=https://json.schemastore.org/mypy.toml would load the mypy file and use it. As will validate-pyproject --tool cibuildwheel=https://json.schemastore.org/cibuildwheel.toml#/properties/tool/properties, etc. What about pyproject-mypy.json? Though some of these are useful on their own; ruff and cibuildwheel work directly on lone configuration files, and even mypy would if you could validate .ini files (they don't have a standalone toml file format, at least currently), etc. I would assume other "nested" schemas could follow a similar pattern.

Possible "partial-pyproject-mypy.json" or "internal-pyproject-mypy.json". I don't mind the "internal", but not fond of the "unstable".

(I'm working on a followup that will load all ref'd schemas in a "store" file (the pyproject.toml one), so the names won't actually be all that exposed soon.)

Validate-pyproject PRs:

• feat: load tool(s) via URL abravalheri/validate-pyproject#121
• feat: add --store to load a schema store abravalheri/validate-pyproject#133
• feat: add fragment support to entrypoints abravalheri/validate-pyproject#134

[hyperupcall]

I see - yeah on second thought, neither 'unstable' or 'internal' are not good names for most of these schemas. I didn't think that some validators could use our URLs to explicitly validate a subschema. The name pyproject-mypy.json sounds good, but I'm thinking it still could be better. Like you mention, ruff and cibuildwheel can be their own file (even if not JSON). And, pyproject-mypy could imply that 'mypy' is somehow dependent on 'pyproject'.

How about this:

• If a schema represents an existing project, that could be its own file (even if INI), then keep the name the same (what is already done)
• If the schema cannot be its own file, I like your idea of prefixing with partial- (partial-mypy.json). If later the project supports a stanadlone config file, we can always $ref the partial.

[henryiii]

Are you suggesting partial-mypy.json or partial-pyproject-mypy.json?

[hyperupcall]

I was a bit vague - partial-mypy.json

[henryiii]

And are you suggesting we change poetry, scikit-build, and setuptools? (hatch, cibuildwheel, and ruff all also can stand alone). (In a later PR, of course)

[hyperupcall]

I do have a slight preference to rename those instances in a backwards-compatible way. For example, renaming poetry.json to partial-poetry.json, and creating a new poetry.json with a $ref to partial-poetry.json. But I don't think it's all that necessary.

If you'd like, I can make the PR doing this. If you aren't in favor, then we can keep poetry skikit-build and setuptools as they are, without changes.

[hyperupcall]

thanks!

[bersbersbers]

Hi, this is great! I am getting two error messages in my pyproject.toml now (VS Code with Even Better TOML):

Additional properties are not allowed ('show_error_codes', 'show_error_code_links' were unexpected)

Some infos on those:

• PR adding show_error_code_links: Add option to show links to error code docs (once per code) python/mypy#15449 (that one should be added to the schema, I guess)

• PR renaming show_error_codes to hide_error_codes, but keeping the former for backwards compatibility: Show error codes by default python/mypy#13542 (that one would be fine to leave out the schema, I guess, although that renaming is hard to find).

[hyperupcall]

@bersbersbers thanks for the report, I have created issue #3467 to track it