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

Support all frameworks on the wall of super powers #19

Closed
Bengt opened this issue Mar 10, 2014 · 4 comments
Closed

Support all frameworks on the wall of super powers #19

Bengt opened this issue Mar 10, 2014 · 4 comments

Comments

@Bengt
Copy link

Bengt commented Mar 10, 2014

The Python 3 Wall of Superpowers features the most downloaded 210 modules of PyPI. At the end of the list, there are still very popular packages like bottle, Zope or Pylons. Prospector should support all of them to help with many use cases.

@jayclassless
Copy link
Contributor

Just because the README only lists Celery and Django doesn't mean that prospector won't work with code using other libraries. It's just that prospector takes extra steps to to address issues with those two that cause problems with tools like pylint.

Have you encountered a specific problem with a framework/library when using prospector?

@carlio
Copy link
Member

carlio commented Apr 2, 2014

As @jayclassless said, all libraries are "supported" out of the box in so far as prospector will be able to run code checks regardless of dependencies.

There are specific helpers for Django and Celery, which improve code checks in those cases, and hopefully I'll be able to add more in the future.

I'll close this issue because either it's a misunderstanding (and #24 was created to address that possibility) or it really is a request for support for 210 different libraries, in which case the scope is so vast that a single ticket makes no sense.

@carlio carlio closed this as completed Apr 2, 2014
@Bengt
Copy link
Author

Bengt commented Apr 2, 2014

Yes, this was indeed a misunderstanding. Extending the helpers and clarifying the readme seems the proper solution to avoid future confusion.

@carlio
Copy link
Member

carlio commented Apr 2, 2014

Good to know, thanks - I'll get busy on making better docs!

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

No branches or pull requests

3 participants