we were seeing isort produce different outputs locally and in docker -
this was due to it having different opinions about whether the tests
module (ie all our unit tests) is a first party (local) or third party
(pip installed) import. It's a first party import, so by defining this
in the setup.cfg isort settings, we can force it to be consistent
between environments.
Note: I don't know why it was different in the first place though
Done using isort[1], with the following command:
```
isort -rc ./app ./tests
```
Adds linting to the `run_tests.sh` script to stop badly-sorted imports
getting re-introduced.
Chosen style is ‘Vertical Hanging Indent’ with trailing commas, because
I think it gives the cleanest diffs, eg:
```
from third_party import (
lib1,
lib2,
lib3,
lib4,
)
```
1. https://pypi.python.org/pypi/isort
PEP8 was renamed to pycodestyle; this issue explains why:
PyCQA/pycodestyle#466
This commit changes our tests to use pycodestyle instead of pep8.
No changes to our code were required as a result.
…or how to move a bunch of things from a bunch of different places into
`app/static`.
There are three main reasons not to use Flask Assets:
- It had some strange behaviour like only
- It was based on Ruby SASS, which is slower to get new features than libsass,
and meant depending on Ruby, and having the SASS Gem globally installed—so
you’re already out of being a ‘pure’ Python app
- Martyn and I have experience of doing it this way on Marketplace, and we’ve
ironed out the initial rough patches
The specific technologies this introduces, all of which are Node-based:
- Gulp – like a Makefile written in Javascript
- NPM – package management, used for managing Gulp and its related dependencies
- Bower – also package management, and the only way I can think to have
GOV.UK template as a proper dependency
…speaking of which, GOV.UK template is now a dependency. This means it can’t be
modified at all (eg to add a global `#content` wrapper), so every page now
inherits from a template that has this wrapper. But it also means that we have a
clean upgrade path when the template is modified.
Everything else (toolkit, elements) I’ve kept as submodules but moved them to a
more logical place (`app/assets` not `app/assets/stylesheets`, because they
contain more than just SASS/CSS).
