If somebody explicitly has a `.flake8` file, presumably they intend to
put flake8 configuration in it, so prefer it to the generic `setup.cfg`
and `tox.ini` from pycodestyle.
The rst_epilog config value in Sphinx allows you to maintain a global
list of replaces or includes that are appended to the text of each
document in your documentation. This allows us to use |Flake8| everywhere
without redefining the replace in every document.
This relies on two things:
1. Properly configuring flake8-import-order to use that style
2. Properly configuring flake8-import-order to know that flake8 is our
application name.
ConfigFileFinder should absolutely handle broken/invalid config files
by refusing to try to parse them. Here we catch the ParsingError,
log the exception, and then return normally. The RawConfigParser
instance is perfectly valid still and will behave as if nothing had
been read and we just need to indicate that we didn't find any files
worthy of reading.
Related to: https://github.com/PyCQA/pycodestyle/issues/506
This proved simpler because I realized something important: Most of the
code that the old integration was using was in fact doing nothing of
value. Since we can't meaningfully allow users to use command-line
options as parameters to `python setup.py flake8`, we just remove the
work that we do to set up those attributes and parse them.
Previously, we forced Flake8 to be installed in whatever Python
environment that the user was using. This allows someone to use Flake8
from a virtual environment, e.g., if you use the tox.ini from this
commit, you can do:
tox -e venv -- flake8 --install-hook git
And that will allow you to use the Python and Flake8 from
./.tox/venv/bin/python. This means that you can avoid installing
Flake8 globally and still have a working commit hook.
If we create our temporary directory structure for our files, we need
to ensure that all the directories (including the ones in the filename)
exist before we copy the contents to that location.
As per [their blog post of the 27th April](https://blog.readthedocs.com/securing-subdomains/) ‘Securing subdomains’:
> Starting today, Read the Docs will start hosting projects from subdomains on the domain readthedocs.io, instead of on readthedocs.org. This change addresses some security concerns around site cookies while hosting user generated data on the same domain as our dashboard.
Test Plan: Manually visited all the links I’ve modified.
