flake8-bandit: Bandit 1.7.3 addition of new positional argument ``fdata`` causes ``TypeError``

Sorry all! Been crazy the last week at work but this should be resolved! Let me know if you see anything that isn’t working right! Cheers and thanks for being patient.

Hey all! I’m happy to update and add a dependabot and accept PRs on this.

Let me take a look at the PR that was opened this morning and I’ll try to work on it later today.

Thank you very much for fixing this! 😃

Would it be also possible do a new flake8-bandit release to pypi?

@Natureshadow I understand that you find it frustrating if a change in an open-source tool breaks your workflow. But remember that these tools are maintained by volunteers in their free time, for you and everybody else. They deserve our kindness and respect.

Here’s some great reading on the topic:

• https://snarky.ca/setting-expectations-for-open-source-participation/
• https://hynek.me/articles/semver-will-not-save-you/

As for the name PyCQA, see https://meta.pycqa.org/introduction.html

We all make mistakes. And even when we don’t, we can’t know in advance that a specific change will break someone’s use case, or not. About naming conventions: sure, they communicate that something is public or private. But to be fair, Bandit’s README and documentation pages never speak about programmatic use, so we could guess that none of its API is public.

There is a way to protect from issues with future bandit releases - set up upper limit for bandit version, like bandit>=1.7.3,<2.0 or even bandit>=1.7.3,<1.8.

Disagree as well, for the reasons you mentioned:

But this requires flake8-bandit to release more often. Also there is no guarantee that 1.7.4 release will not break backward compatibility.

Compatibility can be broken at any time indeed. Upper bounds do not protect your library. And they prevent downstream users to get upgrades. Without upper bounds, sure, things can break more often, but users can exclude the problematic version themselves. Then upstream can either fix the compatibility issue or exclude the version as well.

Upper bounds can still be used of course, but only if you know the excluded range broke or is going to break compatiblity.

It would probably be good to pin the exact bandit version

This is not a good idea for a library. In such a case user will not be able to install another library which requires some other bandit version, as well as just upgrade bandit because some issue was fixed or a new feature was introduced.

If flake8-bandit requires some changes were added only to bandit==1.7.3, requirements.txt should look like bandit>=1.7.3. This allows user to install any other new version of bandit if this is required.

There is a way to protect from issues with future bandit releases - set up upper limit for bandit version, like bandit>=1.7.3,<2.0 or even bandit>=1.7.3,<1.8. But this requires flake8-bandit to release more often.

Also there is no guarantee that 1.7.4 release will not break backward compatibility. Actually, instead of 1.7.3 version https://github.com/PyCQA/bandit/pull/496 commit should be released as 1.8.0 because it caused backward compatibility break in the first place.

@tylerwince thank you! I think that for this to propagate properly we need a new release on PyPI. Would appreciate it!

It’s not a public API: PyCQA/bandit#837 (comment)[https://github.com/PyCQA/bandit/issues/837#issuecomment-1054746340]

Maybe the “Code Quality Authority” should learn about semantic versioning and naming conventions in Python, then.

I found this while investigating why pre-commit broke in CI for all our repos. We don’t use flake8-bandit directly, but it’s used by one of our hooks. For anyone using the flake8 pre-commit hook who finds this and needs a workaround, my team temporarily added a

bandit < 1.7.3 in additional_dependencies in pre-commit config like:

    additional_dependencies:
          # ... other plugins
          - bandit <1.7.3

to unblock our CI until there’s an update.

It would probably be good to pin the exact bandit version in the requirements of this plugin to avoid a similar situation in the future. Not sure how exactly right now but happy to provide a PR if @tylerwince agrees.

Has anyone asked the bandit people why they break the API in a patch release? That’s the real issue here.

It’s not a public API: https://github.com/PyCQA/bandit/issues/837#issuecomment-1054746340

It can do more than that, but we just saw breakage in a patch release, so it would need to pin to exact versions to avoid this situation anyway. Unless you pinned it to a <=1.7.3 until it is tested on newer versions (which dependabot can still update).