mozilla / sugardough

A web application template based on Django.

Sugardough

Sugardough is not activelly maintained and packages are out of date and insecure.

Sugardough is a web application template based on Django. Sugardough is built using Cookiecutter.

Features:

• Django settings with environment variables, using Decouple
• Jinja2 template engine
• Whitenoise
• Docker ready, plus Docker Compose support.
• Sane Flake8 configuration.
• NewRelic ready.
• Travis-CI ready.
• Coveralls ready.
• Sphinx support and ReadTheDocs ready.
• peep ready.
• session-csrf included.

Virtualenv Docker

Create a sugardough project

1. Get cookiecutter:

   $ pip install cookiecutter

2. Run cookiecutter with sugardough template

   $ cookiecutter https://github.com/mozilla/sugardough

3. Done!

Contribute to sugardough

To contribute to sugardough development:

1. Clone this repository

2. Create a virtualenv.

3. Install development requirements using pip:

   $ pip install -r requirements.txt

4. Update the template directory, and cookiecutter.json as well with new variables if needed.

5. Run the regeneration script that auto-creates a test site:

   $ ./bin/regenerate.py

6. Launch the test site to see your changes:

   $ cd test_project/sugardough
   $ docker-compose up

7. Git commit changes.

8. Pull request!

The regenerate.py command can also watch for changes and auto-regenerate the test project:

$ ./bin/regenerate.py --watch

If you want the test project to use a different value for a variable than the default defined in cookiecutter.json, add the value to your ~/.cookiecutterrc file:

default_context:
    project_name: "Foo Bar"

Opinions

• If you want to change the rules for PEP8, go and edit the setup.cfg file.

• If you want to use MySQL instead of PostgreSQL (which is default), edit the generated requirements.txt file and remove the lines about psycopg2 then use peep to add the version of MySQL-python you want to use. You will also need to edit the .travis.yml file accordingly.

• if you want to use pytest add in requirements.txt pytest, py, cov-core and pytest-django. For test coverage you'll also have to add pytest-cov. Next you'll need to edit the .travis.yml file and edit the script part. Instead of coverage run manage.py test it py.test --cov=sugardough.

• Dockerfile uses Python 3. If you want Python 2 change the following line

  apt-get install -y --no-install-recommends build-essential python3 python3-dev python3-pip \

  to

  apt-get install -y --no-install-recommends build-essential python python-dev python-pip

  and remove the next two lines starting with RUN update-alternatives.

License

Sugardough itself is licensed under the Apache 2 license. See the LICENSE file in this repository for the full text of the license. The website projects produced using sugardough use the Mozilla Public License version 2 by default.

sugardough's Issues

What's the point of the settings directory?

Now that we're no longer in the era of settings/local.py solutions, I think it's simpler and neater to just use projectname/settings.py.

There's some magic going on in the existing settings/__init__.py which I don't understand.

Syntax error in @font-face declaration

Currently the CSS that is added to home.jinja defines a src entry as follows:

src: url('https://mozilla.org/media/fonts/FiraSans-Regular.eot?#iefix') ('embedded-opentype'),

This needs to be:

src: url('https://mozilla.org/media/fonts/FiraSans-Regular.eot?#iefix') format('embedded-opentype'),

Headers are clever but aren't clear

I'm following the docs on a new project, but I get an error when I reach step 5:

% ./bin/regenerate.py
no such file or directory: ./bin/regenerate.py

Add gzip and caching support to WhiteNoise

http://whitenoise.readthedocs.org/en/latest/django.html#add-gzip-and-caching-support

Chef is a bad default

The point of the project_author is because the readthedocs sphinx stuff and the setup.py needs a name. "Chef" is maybe deliberately silly so that it prompts the user to no accept it and enter something sensible. However, I worry about users enter their real name. That means the first author of the project puts his/her name all over the project when in fact it's a team effort. Or at least should be.

coverage is never installed

We rely on coverage in travis but we never install it.

We can either add it here or we can make it part of requirements.txt which would be useful for when developers want to do coverage testing locally. And with that, we should add something to the README about how to use it. E.g.:

./manage.py test --with-coverage --cover-erase --cover-html --cover-package=sugardough

`fig run web` requires docker running

I'm a fig newbie but I generated a project and did a pip install fig and tried to run...:

(env)peterbe@Peters-MacBook-Pro:/tmp/foo2$ fig run web
Couldn't connect to Docker daemon - you might need to run `boot2docker up`.

Why would I need docker running just to run runserver?

Should we really include peepin?

I noticed
c37806a
(cc @glogiotatidis )
I wonder if there's value in including it. It's a personal choice to use it and you certainly don't need it in runtime or for running tests.

I don't think it should be included because peep install -r requirements.txt gets really slow if the list starts to get long. That's because peep has to do a LOT of I/O work.

PS. I'm the proud author of peepin :)

Add Cookiecutter to https://wiki.mozilla.org/MOSS/Projects_in_use_by_Mozilla

Shouldn't https://github.com/audreyr/cookiecutter be on the Projects in use by Mozilla?

Coverage 4.0.1

I had the problem, in my sugardough derived project, that coverage failed to be shipped to coveralls because of this error:

Failure to gather coverage: Couldn't read data from '/home/travis/build/peterbe/headsupper/.coverage': CoverageException: Doesn't seem to be a coverage.py data file

I don't fully know or understand why but apparently it can happen due to a mismatch in the coverage installed.
https://bitbucket.org/ned/coveragepy/issues/408/coverageexception-doesnt-seem-to-be-a

Upgrading to 4.0.1 fixed it all.

Tests for sugardough itself

• We should run the sample tests in the reference app (do we have any yet?)
• We should make test that the git hook was run. Ideally a travis post-script should do what the git hook does.
• We should do flake8 on the sugardough itself.

Severe lack of a license

MPL v2.0 or Apache?

bin/test_sugardough_docker.sh leaves running containers

I noticed there were 38 running containers left over from https://ci.us-west.moz.works/view/Sugardough/job/sugardough/ that needed to be manually killed. To do this I ran the following:

for i in $(sudo docker ps | grep sugardough | awk '{print $1}'); do 
    sudo docker stop $i;
done

Upon further investigation I noticed a post-build action with the command docker rm -f echo jenkins${JOB_NAME}${BUILD_NUMBER}| sed s/_//g_db_1 but the running containers all ended in _db_run_1, not _db_1, so I changed the post-build action. I'm noting that here to record the change, but I think the cleanup command should be a script in this repo, and I'll follow up with a PR to add it.

Travis pip install needs --no-deps

When we install the dependencies for travis we want to be as close to peep as possible which is that we can't let it install things it didn't know it needed.

We should add --no-deps to this line

Perhaps we should use peep instead in travis but that makes it much slower and will make it impossible to benefit from travis possibility to use a pip download cache.

Question to name the directory different from the package name

At the moment, when you run cookiecutter and enter a project_name it becomes used for both the directory and the python package instead.

boot2docker should mount volumes now

From what I can tell, boot2docker can now mount volumes properly, so we might want to reword the following: https://github.com/mozilla/sugardough/blob/master/sugardough/README.md#docker-for-development

Can anyone confirm that it works well for them?

Sensible debug serving of static files

As far as I can see, this is still the norm to do:
https://docs.djangoproject.com/en/1.7/howto/static-files/#serving-files-uploaded-by-a-user-during-development

I created a sample project with sugardough and it fails to serve up static files because I don't run collectstatic all the time when I simply have ./manage.py runserver running.

To session_csrf or not to session_csrf

I'm migrating a project from playdoh with django 1.4, doing so by creating a fresh sugardough site and then bringing over pieces from both the site and playdoh as needed.

The current site uses session_csrf, which is standard for playdoh, so I brought this over as well. I was wondering:

1. Is this something that we should include as standard in sugardough? If so I can create a PR.
2. Is there something else that can be done with django 1.7 that would eliminate the need for session_csrf, and/or is there an alternate/better solution to the problem it addresses?

integrate tower?

playdoh used tower which (as I understand it) the l10n folks blessed as the way to generate .po files.

Are there plans to integrate either tower or the things that tower does into sugardough? If not, are there sugardough-based projects that currently do l10n with svn/verbatim and the rest of the existing system Mozilla uses?

Recommended handling of favicon

Is it recommended to use https://github.com/littlepea/django-favicon?

Is our flake8 exclusion to migrations too lax?

In airmozilla I have:

$ cat .pep8
[pep8]
exclude=airmozilla/*/migrations/*

This feels more solid than just "migrations" because it'd match myapp/management/commands/usermigrationscheck.py for example.

Make .travis.yml run tox instead

This way, local development testing can be done with the same "stuff" as what gets run on travis.

Add contribute.json to generated project

Add setup.py and submit to PyPI

I think it'd be cool if the installation process was mostly: pip install sugardough. I envision something like:

1. pip install sugardough
2. questions are asked and the site is generated
3. build site
4. profit!

Not sure how it'll work exactly yet, but I figured I'd go ahead and file this so we could explore.

Make requires.io, coveralls, etc. options at install time

Just an idea: I personally would not use the requires.io and coveralls hookups in this template, and was thinking it'd be nice if things like that were options that I could enable/disable when cookiecutter asks all those questions while generating a project. Same could go for Travis or Docker support.

Thoughts?

Include peep

I think peep.py should be included in the final generated project. I include it in my projects that will use it to install things as the initial vetted code that gets the rest of it.

bin/fabricate-cookiecutter.py needs the changes to be committed first

From my personal usage at least, it seems the bin/fabricate-cookiecutter.py script needs the changes to be committed, for them to be taken into account.

Here's the steps to reproduce the issue:

• make some changes to some files in the sugardough folder
• rm -rf \{\{\ cookiecutter.project_name\ \}\}/
• bin/fabricate-cookiecutter.py

The changes aren't in the {{ cookiecutter.project_name }} folder.

If the changes are first committed, then everything works as expected. This makes it a bit more tedious to test the end result of the changes before pushing them as a PR.

Include django-pipeline?

Should we include django-pipeline for asset packaging?

If yes note: #69 (comment)

Switch to Django LTS

Currently sugardough follows the latest django versions but maybe it makes more sense to switch to Django LTS to encourage the usage of LTS releases.

Discuss!

Questionable default pep8 exceptions

We currently ignore a long list of pep8 errors

I'm sure some of them are good exceptions but I question if this arbitrary, almost personal, choice is really best practice.

If each item was listed with a comment that justifies why we definitely think pep8 is wrong/over-sensitive on each exception, then I think it'd be OK.
After all, who knows what E123 is without a lot of digging.

CC @pmclanahan @glogiotatidis @Osmose

CACHES default setting

When would you not want to have the caching framework available? :)

.jinja as file extension for Jinja templates?

The more I think about it, the more I wonder if maybe having Jinja templates ending in .html instead of something like .jinja is a bad idea. For every other custom format we have a new file extension, and it seems common in other proejcts to use .jinja for Jinja templates. Many syntax plugins for editors also recognize the extension already. It also helps make it clearer in cases where template languages are mixed.

We could still keep the html extension if we want, maybe something like .html.jinja?

Thoughts?

Update instructions to run on py27 in the README file

The README file still mentions the python:[23]-slim docker image which is no longer used since f046ffa

Wrong chown syntax in the dockerfile

The syntax for chown here seems to be wrong, or at the very least is not the most common way to use it. I was expecting it to use a colon between user and group like

RUN chown webdev:webdev -R .