Skip to content
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

Open
adamcunnington-gdt opened this issue Sep 30, 2021 · 3 comments

Comments

@adamcunnington-gdt
Copy link

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:

  • You can only globally ignore paths or patterns, not for specific tools
  • Tool-specific exclude options are not supported consistently. You support an options block for bandit and mypy for example but not for vulture.
  • Prospector has gone to some effort to standardise the way in which you configure the enabling and disabling of certain rules - but not for excluding certain paths.
@adamcunnington-gdt
Copy link
Author

adamcunnington-gdt commented Oct 26, 2021

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:

  • Disable vulture for entire project
  • Disable linting for entire file

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.

@adamcunnington-gdt adamcunnington-gdt changed the title [FEATURE REQUEST] Ignore a path/pattern for 1 tool only [FEATURE REQUEST] Ignore a path/pattern for 1 tool only and generally, allow us to interact with all tool options, not just some Oct 26, 2021
@Pierre-Sassoulas
Copy link
Collaborator

Pierre-Sassoulas commented Oct 26, 2021

I am finding it increasingly hard to justify continuing to use prospector in my projects

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.

I think PycQA needs to take a good look at this and give this some priority.

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.

prospector's configuration interface is broken

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.

@Pierre-Sassoulas
Copy link
Collaborator

I'm using pre-commit which has custom exclude regex for each tool, you might want to look into this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants