Hi, sorry to be away for a few days.
Sorry I should have just mentioned it, I work on mypy. The issue to support pyproject.toml is one of the most popular: https://github.com/python/mypy/issues/5205
While that is true, I would argue it should have authority to decide on build time tool configuration, which is really what is of concern here.
Don’t get me wrong, I love the choice of toml! I’m just communicating that this choice was painful for many users, which I hope we can agree is something to be avoided
I propose the tool should either “Act as if the
pyproject.toml file does not exist (with some deprecation notice)” or “Error that the section is required” and at some future date kill the first option.
I think you are missing the point. As discussed earlier in the thread, multiple competing options with no clear default lead to confusion and needless debate.
I strongly believe that how a project lays out its configuration should be standardized in some way (though it doesn’t have to be at the language level). I think this is the second best decision Rust made after the borrow checker in fact, and a large reason why cargo is such a delight to use. If we look at npm, there is a clear definition of what keys and such should exist in
project.json. If pip requires something and has a documented default, that is as close to an unofficial standard as you can get.
Things don’t need to be PEPs to have people use them. If something is pypa recommended, and that tools makes certain requirements, a lot of people will use it (if not everyone). Just look at pipenv’s popularity as an example.
Wow that is excellent! Thank you so much for working on this, I’m sure many people will be happy to see 1.0 for toml.