Support pyproject.toml for configuration #813
Comments
|
@ZeeD26 - would you be willing to submit a PR? |
|
@IanLee1521 the configuration management in this project is an abysmal nightmare. Until someone has time to do serious refactoring, I strongly advise against accepting this as a feature. |
|
Good point. |
|
Is there more traction now for pyproject.toml format? Seems more prevalent on Github. We are looking at Poetry and this would be useful to have central configuration. |
|
Not really, no |
Now that we're starting to use python's typing module, 80 chars is becoming increasingly restrictive. This commit signals that dimod support 100 characters by adding it to the setup.cfg. Ideally we would like to add it to the pyproject.toml, but right now that's not supported. See PyCQA/pycodestyle#813
The PIP518 support as described in PyCQA#813 has been implemented roughly. It uses the toml package, since the toml package describes itself as being Python 2 compatible. Using another package will create a dependency that might not be wanted. Hence the dependency is treated optional as an extra, so consumers can decide which revision they would like to use. TODO: Unit test must be written explicitely.
|
Hi, I must agree to @sigmavirus24, the configuration is really messed up, but I think I found a simple and backward compliant way of adding this feature. The idea is to read the configuration from the pyproject.toml into a dictionary and add it to the configparser object. To keep the current behavior, that no dependencies must be used, the feature is added as an extra. There are still some things to do before #1007 can be merged:
Please tell me, what you think. |
|
I'm not clear from the discussion: if someone were to implement pyproject.toml support (perhaps via the idea that @carstencodes suggested) would that be welcomed as a contribution? If yes, then it would be appreciated to indicate that clearly so as to encourage a contribution. If not, then I'd suggest this be closed so as to make it clear the format will not be supported (and if that decision is reversed the issue can always be reopened). |
|
I'll try to add the missing parts on the upcoming weekend. Then it's up to the maintainers to merge or reject this PR. As we can see in PyCQA/flake8#234, supporting this issue might be hard to accomplish. Since discussion about pyproject.toml support is too heated for some projects (see flake8), it might be a good idea to wait for a toml parser in python (see https://bugs.python.org/issue40059). Or to use a workaround, like I did with carstencodes/flake518. |
Good idea |
|
I see that pydocstyle supports pyproject.toml - could the same approach be taken in pycodestyle? This seems a fairly popular feature request considering it is both pinned and has received 80+ thumbs up. Maybe a good time to re-open this issue and re-examine, as it is nearing a year since the last update? |
I would love to see support for
pyproject.tomlfor the configuration as, e.g., black doesThe text was updated successfully, but these errors were encountered: