-
Notifications
You must be signed in to change notification settings - Fork 173
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.
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
[FEATURE REQUEST] support configuration in pyproject.toml #376
Comments
Nice. I'll check how to adopt it into the project, but shouldn't be part of the next release by the end of the month yet, prob mid-June. |
This reverts commit 20a155a[^0], because `prospector` doesn't pick up `pep257` options from "setup.cfg", so these options don't actually fix the complaints. This means that, until [prospector-dev/prospector#376][0] is implemented, or until `prospector` implements gathering tool configuration from "setup.cfg", we have to put yet another dotfile into the project root, if we want fine grained control over the applied checks. Since we have to do this anyway, this commit not only removes the section from "setup.cfg", but also puts the equivalent configuration into the new ".prospector.yaml". While at it, I took the liberty of also starting to configure paths which should be ignored by `prospector`, because that one line really doesn't have to be in it's own commit. [0]: prospector-dev/prospector#376 [^0]: 20a155a
This reverts commit 20a155a[^0], because `prospector` doesn't pick up `pep257` options from "setup.cfg", so these options don't actually fix the complaints. This means that, until [prospector-dev/prospector#376][0] is implemented, or until `prospector` implements gathering tool configuration from "setup.cfg", we have to put yet another dotfile into the project root, if we want fine grained control over the applied checks. Since we have to do this anyway, this commit not only removes the section from "setup.cfg", but also puts the equivalent configuration into the new ".prospector.yaml". While at it, I took the liberty of also starting to configure paths which should be ignored by `prospector`, because that one line really doesn't have to be in its own commit. [0]: prospector-dev/prospector#376 [^0]: 20a155a
hey, wanted to check in what the progress on this is, with prospector as well as other tools it integrates(in my case vulture) being able to use pyproject.toml would love to see this happen! |
What is the latest on this? Would be great to see pyproject.toml support for Prospector. It's currently the only tool in the modern dev's toolkit that requires a separate configuration file. |
Would also love this feature. Using poetry, black, and then prospector and having everything be able to be set using pyproject.toml would make me so happy. |
I am tempted to take this on actually, I'd like to move prospector to using poetry for packaging anyway. |
|
@carlio is this still on your radar? |
I would review, merge and release an implementation of this. |
Depends on #442 , intention is to replace how prospector is configured (probably using click?) and in doing so I can include using pyproject.toml as a source. |
Any more progress on this feature? Thx in advance |
Gentle ping: @carlio is this still on the radar ? |
The latest/upcoming releases of python-based tools like pylint (see pylint-dev/pylint#617), coverage (nedbat/coveragepy#664), pytest (pytest-dev/pytest#1556) etc. all support configuration via the
pyproject.toml
file (PEP 518), making it possible to keep the configuration of these tools in one place and unclutter the top level of python package repositories.It would be nice, if
prospector
would support this as well - see also pytest-dev/pytest#1556 (comment) for some more reasoning why this is a good idea.The text was updated successfully, but these errors were encountered: