Closed pslacerda closed 3 years ago
For a number of tools, you have to specify the same parameters in several files, it would be convenient to see them side by side, as well as not have a bunch of files in the root of the project. So, So, I definitely need a configuration in one place.
FYI I wrote a blog post recently explaining pyproject.toml
. I thought it might be useful to share here as at least early on in the discussion here there were some misunderstandings over the purpose of the file.
And selfishly, mypy is the one tool I used on all of my projects, app and package alike, which does not support pyproject.toml
as an option (Black and coverage.py being the other projects). 😁
Not sure what the status is on this issue, but it seems pytest will also start supporting pyproject.toml
for configuration. The PR has already been merged (#7242)
FYI I wrote a blog post recently explaining
pyproject.toml
. I thought it might be useful to share here as at least early on in the discussion here there were some misunderstandings over the purpose of the file.And selfishly, mypy is the one tool I used on all of my projects, app and package alike, which does not support
pyproject.toml
as an option (Black and coverage.py being the other projects). 😁
Just FYI to anyone who is unaware, Black supports pyproject.toml now too: https://black.readthedocs.io/en/stable/pyproject_toml.html
Since PEP 631 is accepted (Dependency specification in pyproject.toml), it seems like pyproject.toml is cemented as the way to do project configuration and setup.cfg is going the way of the dodo.
@ethanhs since you said you’d maintain this if it’s accepted: what’s the decision of the team regarding this in 2021?
I don't think I can still make that offer considering the other time demands I have. I'm happy to help in review and maintenance, but I am too busy to be the sole maintainer. It would be great for mypy to support pyproject.toml for configuration, but I think someone will have to step forward to implement support for it, and that hasn't happened yet.
Since PEP 631 is accepted (Dependency specification in pyproject.toml), it seems like pyproject.toml is cemented as the way to do project configuration and setup.cfg is going the way of the dodo.
PyPA’s position has always been, and likely will continue be that pyproject.toml
is only cemented as the way to declare packaging metadata. We do not encourage projects to store non-packaging-related configuration in pyproject.toml
(although we don’t stop projects if they insist). It would be perfectly appropriate if Mypy decides to not support configuring with pyproject.toml
at all.
It is also not accurate to say setup.cfg
is going to be obsolete. Packaging tools are still free to use their own configuration file for things specific to themselves (i.e. things not relevant to any other packaging tools), and I can see setuptools continuing to support setup.cfg
for those usages even after they implement PEP 631. The thing that might loose popularity is using setup.cfg
as the de-facto standard project-level configuration file. Mypy can choose to drop support to setup.cfg
(because using setup.cfg
in this way will no longer be popular), support pyproject.toml
(because it’s okay to do it and people want it), or do neither or both.
We do not encourage projects to store non-packaging-related configuration in
pyproject.toml
I'm not disagreeing with anything you said, but I do think it's worth pointing out that PEP 518 explicitly defines the [tool]
table as an official mechanism for tools to define non-packaging-related configuration in pyproject.toml
. To me that is at least an implicit nod towards projects doing this if they wish.
An earlier version of PEP 518 led to a lot of finger-pointing when Black and Towncrier (examples from the top of my head, there may be more) started to use the tool
table. The language was soften to stop the argument, but PyPA’s stance does not change much.
Let's face it, the "PyPA’s stance" is just an opinion of a small number of community members which clearly contradicts the process actually happening in the community and the request for that being highly spread.
I think a better way to phrase it is the PyPA is not mandating tools use pyproject.toml
for tool configuration outside of what is already in PEPs (e.g. PEP 517 and 518), but the support for doing so is definitely there and available for tools that want to use it (hence the "do not encourage" from @uranusjr ; it's not the same as "discourage", just that the PyPA is not taking a stance since it's way beyond any mandate or purview of PyPA to do so).
Personally, I want tools to use it. 😉
Ok there has been much talk about this issue, and since it is re-opened, I'm guessing that the mypy maintainers would be willing to humor pull-requests from the community.
So, maybe it's time to shift the discussion from "gosh I wish this feature were implemented" to "how can this feature be implemented".
Exactly. The next step here should be a pull request. I'll try to make time to review it, but first we need a pull request.
I am not familiar with mypy internals. Does mypy have some sort of config IR that is used as a destination for both mypy.ini
files and command line arguments?
(I'm thinking that, if so, this config IR could be a destination for pyproject.toml
too)
Any plan to do a release with this feature ?
Hopefully there's a new release within the next month (as always, no promises).
I hope so, because the docs are already updated and as a new user I've just spent an hour wondering why I couldn't get it to work. Then I found this issue. :clown_face:
I understand this is closed but I'm trying to understand why something I used before doesn't work. I was at least able to do this before:
poetry run mypy --config-file pyproject.toml tests
In my pyproject.toml
I would have:
[mypy]
[mypy-expects]
ignore_missing_imports = true
This would work. The message about missing imports would be gone for the expects library. It no longer does when I'm using 0.910. In fact, it looks like it stopped working in 0.900. If I go back to 0.812, it works fine.
I was just calling this out to make sure if this was a deliberate change.
I understand this is closed but I'm trying to understand why something I used before doesn't work. I was at least able to do this before:
poetry run mypy --config-file pyproject.toml tests
In my
pyproject.toml
I would have:[mypy] [mypy-expects] ignore_missing_imports = true
This would work. The message about missing imports would be gone for the expects library. It no longer does when I'm using 0.910. In fact, it looks like it stopped working in 0.900. If I go back to 0.812, it works fine.
I was just calling this out to make sure if this was a deliberate change.
The syntax in pyproject.toml is a little different, you need to use [[tool.mypy.overrides]]
sections. It's in the docs somewhere.
The syntax in pyproject.toml is a little different, you need to use
[[tool.mypy.overrides]]
sections. It's in the docs somewhere.
Ah! Much thanks. Yes, I did find it here: https://mypy.readthedocs.io/en/stable/config_file.html#using-a-pyproject-toml-file
PEP518 says that
pyproject.toml
is to support the minimum build requirements. I want to consider mypy as part of the minimum build on my package.For example Pip uses a
[tool.towncrier]
section onpyproject.toml
to generate a correctly updatedNEWS.rst
as part of its build. One can considers typing correctness as important to the distributed source pakcage as an well documentedNEWS.rst
. Other example is Black that also has it section onpyproject.toml
.Maybe you think that this is a silly feature request and that
setup.cfg
must be used instead, Pip or Flit or whatever can setup mypy after all. But an TOML module will be added to the standard library sooner or later, than could mypy accept this feature and antecipate TOML supportingpyproject.toml
today?