-
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] Ignore a path/pattern for 1 tool only and generally, allow us to interact with all tool options, not just some #448
Comments
Can someone comment on whether the understanding of current limitation here is correct? To provide a concrete example, just today, I was trying to disable vulture, only, for 1 file, only. A python module within my package implements a CLI interface and so obviously there are functions in here that are uncalled (because they're called via console script entry points). Vulture is complaining about them. Vulture doesn't support inline-ignore comments, nor file-level ignore comments. Prospector does not allow me to disable vulture for only 1 file and prospector does not allow me to interact with the full set of vulture options. Thus, my options are reduced to:
Both of these options are bad. I am all for standardising interfaces and generalising patterns but I think I would go as far as to say that prospector's configuration interface is broken. It still is not exposed via pyproject.toml, which takes away from prospector's goals to standardise configuration and minimise additional files. The architecture of the interface leaves a lot to be desired; I am not able to interact with lots of tool-specific options, the documentation is patchy. I am finding it increasingly hard to justify continuing to use prospector in my projects but this makes me really sad because I SO support the goals of what this project is trying to achieve. I think PycQA needs to take a good look at this and give this some priority. @Pierre-Sassoulas, I'd be grateful for your comments here. I also just discovered that you cannot pass options to pylint extensions. Now I have to have a .pylintrc file - this not only goes against the purpose of having prospector but it's actually almost worse than using many tools directly, explicitly, because now my dev workflow is harder to reason about. |
At the end of the day prospector is open-source software that someone is providing to you for free, so there's no incentives for maintainers to make you want to use it again.
PycQA was made aware that prospector was abandoned already. I took a look at this, Carl took the time to give me the admin right, and now I'm minimally maintaining this project. Which means I added the necessary continuous integration to be able to test merge request and release the package if required. Which is already a lot more than most people did for prospector - and I'm not even using prospector myself. But the original maintainer are missing / doing something else and no one want to really take on the project so far. I'm not going to start adding features that's for sure.
Your best bet is to fix it yourself and open one or multiple merge request which I will review and merge if it's reviewable and mergeable in a reasonable time. Or you can find another person willing to maintain prospector and if one of the current three admins trust them enough they might become the new maintener. Ultimately if no one using it care enough to make the change required, then the project is going to stay in its current state which might be good enough for most, or might not be good enough and the project is going to slowly die. |
I'm using |
Perhaps I'm missing something really obvious here because it seems really strange to me that this behaviour is not supported out of the box but as far as I can tell from the documentation:
The text was updated successfully, but these errors were encountered: