Some other additions to PyCQA possibly
Hi there, There are a few other things that came out of the ashes of Landscape.io that may or may not make sense to move into PyCQA too: 1) pylint-celery - this one I don’t think anyone uses and it isn’t very useful anyway 2) pylint-plugin-utils - this is used by pylint-django and pylint-celery as far as I know, I’m not sure how useful it is outside of that 3) prospector - this is the bigger one, lots of people use this, but I can understand that it might not be in the same state of mind as the rest of the PyCQA code :-) Let me know what you think either way! Carl
Hi Carl,
From my point of view, they could all live in the organisation, at least pylint-plugin-utils and prospector still seem useful to folks.
On Thu, Mar 8, 2018 at 6:58 PM, Carl Crowder <carl.crowder@gmail.com> wrote:
Hi there,
There are a few other things that came out of the ashes of Landscape.io that may or may not make sense to move into PyCQA too:
1) pylint-celery - this one I don’t think anyone uses and it isn’t very useful anyway 2) pylint-plugin-utils - this is used by pylint-django and pylint-celery as far as I know, I’m not sure how useful it is outside of that 3) prospector - this is the bigger one, lots of people use this, but I can understand that it might not be in the same state of mind as the rest of the PyCQA code :-)
Let me know what you think either way!
Carl
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
I would say that the motivation of pylint-plugin-utils was twofold: First - it was a bit of a pain to try to figure out how to write a plugin. This was about 5 years ago though so not sure if that is still true but it took me a while to figure out. Docs on that could be better. Second - it was really just a utility to make it easier to do several things which were useful, such as “skip this error in this context” or “add this error in this context”. I definitely think the plugin API in pylint could be easier to use, I’m not sure if pylint-plugin-utils is the answer because it’s just a bandaid really. It could be useful to see the symptoms it was trying to solve though. Carl On 8 March 2018 at 21:51:29, Ashley Whetter (ashley@awhetter.co.uk) wrote: Does it make more sense to try and merge pylint plugin utils into pylint core? If the plugin interface is clunky enough on its own that there exists utilities for creating plugins, then I think that's an issue that we need to look at resolving. I've been taking a look at this repository recently for the per directory config project in pylint to get sense of how the plugin interface is being used and getting ideas for the kind of thing that we should be aiming for. Ashley
Any news on moving prospector to PyCQA? Em 8 de mar de 2018, à(s) 21:06, Carl Crowder <carl.crowder@gmail.com> escreveu:
I would say that the motivation of pylint-plugin-utils was twofold:
First - it was a bit of a pain to try to figure out how to write a plugin. This was about 5 years ago though so not sure if that is still true but it took me a while to figure out. Docs on that could be better.
Second - it was really just a utility to make it easier to do several things which were useful, such as “skip this error in this context” or “add this error in this context”.
I definitely think the plugin API in pylint could be easier to use, I’m not sure if pylint-plugin-utils is the answer because it’s just a bandaid really. It could be useful to see the symptoms it was trying to solve though.
Carl
On 8 March 2018 at 21:51:29, Ashley Whetter (ashley@awhetter.co.uk) wrote:
Does it make more sense to try and merge pylint plugin utils into pylint core? If the plugin interface is clunky enough on its own that there exists utilities for creating plugins, then I think that's an issue that we need to look at resolving. I've been taking a look at this repository recently for the per directory config project in pylint to get sense of how the plugin interface is being used and getting ideas for the kind of thing that we should be aiming for.
Ashley
code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
Hi there, Finally got around to moving this. Since it's so tightly tied to Landscape.io I wasn't quite sure the best way to do it but that project is EOL really. Finally made the leap. Prospector is now under PyCQA. Cheers, Carl On 22/03/2018 01:48:06, Carlos Coêlho <carlospecter@gmail.com> wrote: Any news on moving prospector to PyCQA? Em 8 de mar de 2018, à(s) 21:06, Carl Crowder <carl.crowder@gmail.com [mailto:carl.crowder@gmail.com]> escreveu: I would say that the motivation of pylint-plugin-utils was twofold: First - it was a bit of a pain to try to figure out how to write a plugin. This was about 5 years ago though so not sure if that is still true but it took me a while to figure out. Docs on that could be better. Second - it was really just a utility to make it easier to do several things which were useful, such as “skip this error in this context” or “add this error in this context”. I definitely think the plugin API in pylint could be easier to use, I’m not sure if pylint-plugin-utils is the answer because it’s just a bandaid really. It could be useful to see the symptoms it was trying to solve though. Carl On 8 March 2018 at 21:51:29, Ashley Whetter (ashley@awhetter.co.uk [mailto:ashley@awhetter.co.uk]) wrote: Does it make more sense to try and merge pylint plugin utils into pylint core? If the plugin interface is clunky enough on its own that there exists utilities for creating plugins, then I think that's an issue that we need to look at resolving. I've been taking a look at this repository recently for the per directory config project in pylint to get sense of how the plugin interface is being used and getting ideas for the kind of thing that we should be aiming for. Ashley _______________________________________________ code-quality mailing list code-quality@python.org [mailto:code-quality@python.org] https://mail.python.org/mailman/listinfo/code-quality [https://mail.python.org/mailman/listinfo/code-quality]
Woot!!! On Fri, Apr 6, 2018 at 5:37 PM, Carl Crowder <carl.crowder@gmail.com> wrote:
Hi there,
Finally got around to moving this. Since it's so tightly tied to Landscape.io I wasn't quite sure the best way to do it but that project is EOL really. Finally made the leap.
Prospector is now under PyCQA.
Cheers, Carl
On 22/03/2018 01:48:06, Carlos Coêlho <carlospecter@gmail.com> wrote:
Any news on moving prospector to PyCQA?
Em 8 de mar de 2018, à(s) 21:06, Carl Crowder <carl.crowder@gmail.com> escreveu:
I would say that the motivation of pylint-plugin-utils was twofold:
First - it was a bit of a pain to try to figure out how to write a plugin. This was about 5 years ago though so not sure if that is still true but it took me a while to figure out. Docs on that could be better.
Second - it was really just a utility to make it easier to do several things which were useful, such as “skip this error in this context” or “add this error in this context”.
I definitely think the plugin API in pylint could be easier to use, I’m not sure if pylint-plugin-utils is the answer because it’s just a bandaid really. It could be useful to see the symptoms it was trying to solve though.
Carl
On 8 March 2018 at 21:51:29, Ashley Whetter (ashley@awhetter.co.uk) wrote:
Does it make more sense to try and merge pylint plugin utils into pylint core? If the plugin interface is clunky enough on its own that there exists utilities for creating plugins, then I think that's an issue that we need to look at resolving. I've been taking a look at this repository recently for the per directory config project in pylint to get sense of how the plugin interface is being used and getting ideas for the kind of thing that we should be aiming for.
Ashley
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
Awesome Carl! Are there any plans on opening new spots for prospector maintainers? On Fri, Apr 6, 2018 at 8:24 PM Ian Stapleton Cordasco < graffatcolmingov@gmail.com> wrote:
Woot!!!
Hi there,
Finally got around to moving this. Since it's so tightly tied to Landscape.io I wasn't quite sure the best way to do it but that project is EOL really. Finally made the leap.
Prospector is now under PyCQA.
Cheers, Carl
On 22/03/2018 01:48:06, Carlos Coêlho <carlospecter@gmail.com> wrote:
Any news on moving prospector to PyCQA?
Em 8 de mar de 2018, à(s) 21:06, Carl Crowder <carl.crowder@gmail.com> escreveu:
I would say that the motivation of pylint-plugin-utils was twofold:
First - it was a bit of a pain to try to figure out how to write a
This was about 5 years ago though so not sure if that is still true but it took me a while to figure out. Docs on that could be better.
Second - it was really just a utility to make it easier to do several
On Fri, Apr 6, 2018 at 5:37 PM, Carl Crowder <carl.crowder@gmail.com> wrote: plugin. things
which were useful, such as “skip this error in this context” or “add this error in this context”.
I definitely think the plugin API in pylint could be easier to use, I’m not sure if pylint-plugin-utils is the answer because it’s just a bandaid really. It could be useful to see the symptoms it was trying to solve though.
Carl
On 8 March 2018 at 21:51:29, Ashley Whetter (ashley@awhetter.co.uk) wrote:
Does it make more sense to try and merge pylint plugin utils into pylint core? If the plugin interface is clunky enough on its own that there exists utilities for creating plugins, then I think that's an issue that we need to look at resolving. I've been taking a look at this repository recently for the per directory config project in pylint to get sense of how the plugin interface is being used and getting ideas for the kind of thing that we should be aiming for.
Ashley
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
_______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
-- *Carlos Coêlho* Software Developer Hangout: carlos@vinta.com.br Skype: carloshf.oliveira We design, develop and fix beautiful software. *http://www.vinta.com.br/ <http://www.vinta.com.br/>*
Hi Carlos, I am definitely keen to add more maintainers. If you are interested - and the same is true for anyone on this list - just drop me an email and we can discuss :-) Carl On 20/04/2018 23:31:59, Carlos Coêlho <carlospecter@gmail.com> wrote: Awesome Carl! Are there any plans on opening new spots for prospector maintainers? On Fri, Apr 6, 2018 at 8:24 PM Ian Stapleton Cordasco <graffatcolmingov@gmail.com [mailto:graffatcolmingov@gmail.com]> wrote: Woot!!! On Fri, Apr 6, 2018 at 5:37 PM, Carl Crowder <carl.crowder@gmail.com [mailto:carl.crowder@gmail.com]> wrote:
Hi there,
Finally got around to moving this. Since it's so tightly tied to Landscape.io I wasn't quite sure the best way to do it but that project is EOL really. Finally made the leap.
Prospector is now under PyCQA.
Cheers, Carl
On 22/03/2018 01:48:06, Carlos Coêlho <carlospecter@gmail.com [mailto:carlospecter@gmail.com]> wrote:
Any news on moving prospector to PyCQA?
Em 8 de mar de 2018, à(s) 21:06, Carl Crowder <carl.crowder@gmail.com [mailto:carl.crowder@gmail.com]> escreveu:
I would say that the motivation of pylint-plugin-utils was twofold:
First - it was a bit of a pain to try to figure out how to write a plugin. This was about 5 years ago though so not sure if that is still true but it took me a while to figure out. Docs on that could be better.
Second - it was really just a utility to make it easier to do several things which were useful, such as “skip this error in this context” or “add this error in this context”.
I definitely think the plugin API in pylint could be easier to use, I’m not sure if pylint-plugin-utils is the answer because it’s just a bandaid really. It could be useful to see the symptoms it was trying to solve though.
Carl
On 8 March 2018 at 21:51:29, Ashley Whetter (ashley@awhetter.co.uk [mailto:ashley@awhetter.co.uk]) wrote:
Does it make more sense to try and merge pylint plugin utils into pylint core? If the plugin interface is clunky enough on its own that there exists utilities for creating plugins, then I think that's an issue that we need to look at resolving. I've been taking a look at this repository recently for the per directory config project in pylint to get sense of how the plugin interface is being used and getting ideas for the kind of thing that we should be aiming for.
Ashley
_______________________________________________ code-quality mailing list code-quality@python.org [mailto:code-quality@python.org] https://mail.python.org/mailman/listinfo/code-quality [https://mail.python.org/mailman/listinfo/code-quality]
_______________________________________________ code-quality mailing list code-quality@python.org [mailto:code-quality@python.org] https://mail.python.org/mailman/listinfo/code-quality [https://mail.python.org/mailman/listinfo/code-quality]
-- Carlos Coêlho Software Developer Hangout: carlos@vinta.com.br [mailto:carlos@vinta.com.br] Skype: carloshf.oliveira We design, develop and fix beautiful software. http://www.vinta.com.br/ [http://www.vinta.com.br/]
participants (5)
-
Ashley Whetter -
Carl Crowder -
Carlos Coêlho -
Claudiu Popa -
Ian Stapleton Cordasco