EDIT: nevermind, couldn't reproduce it with a new virtualenv. Whatever problem occurred in that virtualenv likely wasn't that interesting (wild guess is a package name collision).

pypy2-v5.3.1-linux64 / [PyPy 5.3.1 with GCC 4.8.2]

If you can't reproduce it with that tarball I'll dig deeper to see the mechanism of failure, maybe it's not pypy and it's just something local to my config or venv.

Checked the same tarball (downloaded from bitbucket) and still can't repro. Just in case, what I'm doing is:

   cd path/to/bandit
   virtualenv -p path/to/pypy venv
   venv/bin/pip install -r./requirements.txt -e .
   venv/bin/bandit-config-generator -o tmp_file
   venv/bin/bandit -c tmp_file -r path/to/some/project

I did something similar, yes. I cannot reproduce this with a new virtualenv anymore. It may have been due to odd bits in my environment (likely not worth further investigation).

    virtualenv -p `which pypy` ~/pypy_env
    source ~/pypy_env/bin/activate
    # indeterminate <but probably critical> changes to this venv
    pip install bandit
    bandit-config-generator -o tmp_file
    bandit --help # "The following sets..." is empty
    bandit -c tmp_file -r path/to/some/project # gives the error regarding config file parse failure

I can reproduce the parse error given the nearly empty config file, but it's not clear to me whether the parse error is expected in this case or not.

    $ echo -e 'tests:\nskips:\n{}' > parse_err.cfg
    $ bandit -c parse_err.cfg .

[main] ERROR parse_err.cfg : Error parsing file.