2016-01-12 09:38:55 +00:00
[](https://requires.io/github/alphagov/notifications-admin/requirements/?branch=master)
2016-04-07 10:28:29 +01:00
[](https://coveralls.io/github/alphagov/notifications-admin?branch=master)
2015-11-23 14:55:37 +00:00
2015-11-18 16:41:49 +00:00
2015-11-20 10:31:28 +00:00
# notifications-admin
2015-11-18 16:32:15 +00:00
2016-03-03 07:41:53 +00:00
GOV.UK Notify admin application.
2015-11-23 14:37:29 +00:00
2016-02-03 15:18:57 +00:00
## Features of this application
2015-11-23 14:31:14 +00:00
2016-03-03 07:41:53 +00:00
- Register and manage users
- Create and manage services
- Send batch emails and SMS by uploading a CSV
2016-02-03 15:18:57 +00:00
- Show history of notifications
Use a Node-based tools for handling assets
…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).
2015-12-15 08:20:25 +00:00
2016-02-03 15:18:57 +00:00
## First-time setup
Use a Node-based tools for handling assets
…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).
2015-12-15 08:20:25 +00:00
2017-04-18 14:04:10 +01:00
Brew is a package manager for OSX. The following command installs brew:
```shell
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
```
2016-03-03 07:41:53 +00:00
Languages needed
2016-08-17 15:59:16 +01:00
- Python 3.4
2016-11-21 17:24:26 +00:00
- [Node ](https://nodejs.org/ ) 5.0.0 or greater
- [npm ](https://www.npmjs.com/ ) 3.0.0 or greater
2017-04-18 14:04:10 +01:00
```shell
brew install node
```
Use a Node-based tools for handling assets
…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).
2015-12-15 08:20:25 +00:00
2016-03-03 07:41:53 +00:00
[NPM ](npmjs.org ) is Node's package management tool. `n` is a tool for managing
different versions of Node. The following installs `n` and uses the latest
version of Node.
2016-01-14 16:26:56 +00:00
```shell
2016-01-06 11:14:04 +00:00
npm install -g n
2017-08-16 15:25:26 +01:00
n latest
2016-01-06 11:14:04 +00:00
npm rebuild node-sass
2016-01-14 16:26:56 +00:00
```
2016-01-12 13:37:50 +00:00
2016-08-17 15:59:16 +01:00
The app runs within a virtual environment. We use mkvirtualenv for easier working with venvs
Use a Node-based tools for handling assets
…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).
2015-12-15 08:20:25 +00:00
```shell
2016-08-17 15:59:16 +01:00
pip install virtualenvwrapper
2016-02-03 15:18:57 +00:00
mkvirtualenv -p /usr/local/bin/python3 notifications-admin
2016-03-03 07:41:53 +00:00
```
Install dependencies and build the frontend assets:
```shell
2016-08-17 15:59:16 +01:00
workon notifications-admin
2016-02-03 15:18:57 +00:00
./scripts/bootstrap.sh
Use a Node-based tools for handling assets
…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).
2015-12-15 08:20:25 +00:00
```
2016-03-03 07:41:53 +00:00
## Rebuilding the frontend assets
2015-11-23 14:31:14 +00:00
2016-02-03 15:18:57 +00:00
If you want the front end assets to re-compile on changes, leave this running
in a separate terminal from the app
```shell
npm run watch
```
2015-12-10 16:47:29 +00:00
2016-03-23 14:09:07 +00:00
## Create a local environment.sh file containing the following:
```
echo "
2016-08-04 18:01:08 +01:00
export NOTIFY_ENVIRONMENT='development'
2017-11-06 13:07:21 +00:00
export FLASK_APP=application.py
export FLASK_DEBUG=1
export WERKZEUG_DEBUG_PIN=off
2016-03-23 14:09:07 +00:00
"> environment.sh
```
2016-09-06 10:22:20 +01:00
## AWS credentials
2016-08-17 15:59:16 +01:00
Your aws credentials should be stored in a folder located at `~/.aws` . Follow [Amazon's instructions ](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files ) for storing them correctly
2016-03-23 14:09:07 +00:00
2016-02-03 15:18:57 +00:00
## Running the application
```shell
workon notifications-admin
./scripts/run_app.sh
```
2015-11-25 15:29:12 +00:00
2016-03-03 07:41:53 +00:00
Then visit [localhost:6012 ](http://localhost:6012 )
2018-07-10 15:16:14 +01:00
## Updating application dependencies
`requirements.txt` file is generated from the `requirements-app.txt` in order to pin
versions of all nested dependencies. If `requirements-app.txt` has been changed (or
we want to update the unpinned nested dependencies) `requirements.txt` should be
regenerated with
```
make freeze-requirements
```
`requirements.txt` should be committed alongside `requirements-app.txt` changes.