This changeset updates the README.md file with a set of entirely new instructions. These updates are intended to improve clarity, simplify steps, and reduce confusion and environment-setup gotchas that folks have run into previously and we have learned from. A couple of other changes are also included:
- Minor adjustments to the Makefile to improve make bootstrap
- Updates to the sample.env file to include previously missing required environment variables and/or information
- Additional support for Python virtual environments
- Removes tracking of the .python-version file used by pyenv
Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
This changeset takes care of leaving E2E tests in a clean state so that
we can revisit the work later. The efforts to add authentication
support did not pan out, so we will go a different route in the near
future.
Signed-off-by: Carlo Costino <carlo.costino@gsa.gov>
Creates a "v2" package-lock.json file for consistent dependency
installation.
Lock file created using `npm i --package-lock-only`
Signed-off-by: Richard Baker <richard.baker@digital.cabinet-office.gov.uk>
We need to give people a better feel for the consequences of
broadcasting an alert. We’ve seen in research that some users will
assume it is subscription based, or opt-in, rather than going to every
phone in the area.
I reckon that the most effective way to communicate this is to put some
numbers next to the areas, to give people an idea of how many people
will get alerted.
We can estimate how many phones are in an area by:
- taking the population of all electoral wards in that area
- multiplying it by the percentage of people who own an internet
connected phone[1]
The Office for National Statistics publish both these datasets.
The number of people who own an intenet connected phone varies a lot by
age. Since the population data for each ward is broken down by age we
can factor this in. Simplified, the calculation looks like this:
- take the _Abbey_ ward of _Barking and Dagenham_
- in this ward there are 26 people aged 80
- 40% of people over 65 have an internet-connected phone
- therefore 10 of these 80-year-olds would be likely to receive a
broadcast
- (repeat for all other ages)
These numbers won’t be exact, but should be enough to give people a feel
for the severity of what they’re about to do. We can see if they acheive
this aim in user research.
1. This is a proxy for the number of people who are likely to have a 4G
capable phone, because only 4G capable phones will be receiving
broadcasts to begin with
maps lower tier local authorities to upper tier local authorities -
translation for humans: Maps districts to the counties that they are in.
For counties, a row looks like:
`255,E07000105,Ashford,E10000016,Kent`
(E07000105=Ashford, E10000016=Kent)
For unitary districts it maps that district to itself, eg:
`49,E06000052,Cornwall,E06000052,Cornwall`
where both codes are the same
`app/.gitignore` existed to list anything that we
wanted ignored from the repository but not listed
in `.cfignore` (which just symlinked the
`.gitinore` at the root).
Now `.gitignore` and `.cfignore` are split, this
is no longer necessary.
Pytest moved its cache from `./.cache` (which is in our `.gitignore`) to
`./.pytest_cache` (which isn’t).
It’s annoying having to be careful not to commit it all the time, so
this commit makes it ignored.
See https://github.com/pytest-dev/pytest/issues/3286 for more context.
I don’t think we’re getting any benefit from it. Especially since we’re
not running any Node code in production, but just using it to build the
frontend.
The downside is we keep getting these massive diffs which means we don’t
get an accurate line count on pull requests.
Followed instructions here:
https://codeburst.io/disabling-package-lock-json-6be662f5b97d
Previously we used AWS which meant that we could create wheels
from our requirements and then install them offline which made
deployments quicker.
We're no longer using AWS so let's remove that.
Although CloudFoundry supports installing dependencies in an offline
environment as documented here:
http://docs.cloudfoundry.org/buildpacks/python/#vendoring
To achieve this we create a vendor/ directory which will contain
the packages to install. This uses --no-index and --find-links so will
not resolve for any dependencies from pypi. For this reason there is
assumed confidence that the vendor/ directory will contain all
of the dependencies we need.
…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).
Since GOV.UK Elements is versionned now it makes sense to bring it in as a
dependency. This enforces a separation between what generic stuff we’re using
from Elements and what is specific to our app.
The benefit is that when the generic stuff changes it will be easy to bring
those changes in.
This commit also bumps GOV.UK frontend toolkit to the latest version (v4.5.0).
