search

plone / plone.recipe.codeanalysis

provides static code analysis for Buildout-based Python projects, including flake8, JSHint, CSS Lint, and other code checks
https://pypi.org/project/plone.recipe.codeanalysis/
11 stars 5 forks source link

Remove debug statements #158

Closed gforcada closed 9 years ago

gforcada commented 9 years ago

@tisto good point, updated the next release version to 2.1

do3cc commented 9 years ago

I miss the information in the docs, which flake8 plugins provide this feature.

gforcada commented 9 years ago

@do3cc you are right, I did that branch on the tram and I had no Internet connection, I was planning to add it afterwards, thanks for the reminder!

gforcada commented 9 years ago

I even found a bit misleading the name as I expected that pdb usage would also get a warning, but we were only checking for print statements.

I pointed to both of them on the changelog entry.

hvelarde commented 9 years ago

occurrences of pdb are being tested here: https://github.com/plone/plone.recipe.codeanalysis/blob/master/plone/recipe/codeanalysis/tests/test_flake8.py#L63:L72

BTW, seem that the tests for ipdb have a typo; I fixed here: #159

tisto commented 9 years ago

@gforcada did you update the docs/changelog yet? Apart from this I think this pr can be merged.

hvelarde commented 9 years ago

squash all commits into one first, please

gforcada commented 9 years ago

@tisto yes I added a changelog entry and bumped the version to 2.1, travis was complaining let's see if it's ok now...

tisto commented 9 years ago

@gforcada can we add the new flake8-plugins to our README as "best practice"?

gforcada commented 9 years ago

I was thinking that we should copy zest.releaser and create a [recommended] extra for p.r.codeanalysis where we add all these flake8 plugins that we think should be... ehem .. recommended, does it make sense?

As you can see from my last tweets I'm basically stripping everything python-only related from p.r.codeanalysis and putting it on its own distribution, so we can make them more flexible and useful for others and have different development cycles, while on p.r.codeanalysis should be basically the syntactic sugar to put everything together.

tisto commented 9 years ago

[recommended] sounds good to me. Though, I would also be ok with just adding our recommended plugins to the README. I usually copy the config from there anyways.

Regarding your flake8-plugins: That's really awesome! I always had that vision that p.r.codeanlysis just becomes a thin layer around generic python code analysis tools. Thanks a lot for working on this!!! Factor out as much as possible, less options is good.