Include a Django project with ICEkit. #3
Merged
Conversation
* Make `icekit` a Django project, not just an app (settings modules, root URLconf, etc.) so we run ICEkit as-is (via Docker Compose) or install (via Pip), without needing to customise or maintain any boilerplate project code. * An ICEkit project directory is now just a container for docker compose and stack files, static file and template overrides (front-end customisation) and runtime files (media, logs, etc.) Anticipate feature customisations will be facilitated via `django-model-settings` or possibly a restricted JSON config placed in the project directory that is parsed into allowed ICEkit/Django settings at startup. E.g. thumbnail aliases. * Get started with a bash one-liner that creates a new project directory that you can immediately run via Docker Compose or deploy to Docker Cloud. No build step required. * When run with Docker Compose, services are decoupled (no more `manage.py supervisor`) so they can be scaled separately. * Database migrations are applied and local Node modules and Python requirements are installed automatically as required during container startup. A Redis lock is acquired for each command to prevent multiple containers from trying to update a shared resource (e.g. database, `node_modules` directory, etc.) at the same time. * Alternatively, `pip install icekit` and then use `manage.py icekit ...` to create a project directory and `manage.py supervisor` to run it. You must install Elasticsearch, Redis, PostgreSQL, etc., manually. * Alternatively, continue to install and use `django-icekit` as a library in a full blown custom project. * From a git working copy, just run `docker-compose build` and then `docker-compose up`. This should be much easier to develop ICEkit in isolation, without needing to develop as part of a client project (which probably has many custom templates and features) or run the `startproject.sh` script from a working copy to create a functional version of ICEkit to test changes against. * Replace Bower with NPM to simplify front-end asset management. * Use `pip` instead of `pip-accel` because it wasn't playing nice with the alternate installation user scheme. Anticipating fewer builds being required, the speed of Pip should be less of an issue. * Decouple PostgreSQL environment and database setup. * Just use `manage.py runserver` for WSGI process for now. Anticipate adding Nginx and Gunicorn. * Get master password from environment, making it easy to specify at runtime without having to create a compose override file and without having to commit a default weak password. * Because of the way Docker extends services (you cannot extend a service with links, sequences are combined/extended and not replaced), we need to split the service definition into two files. A compose file (missing links and exposed ports) and an override file. Since we don't need to provide AWS credentials (for pip-accel) or a master password in the override file, this should not be a problem. We can also resort to using `env_file` to provide secrets. * Get rid of `SITE_VERBOSE_NAME` and add `SITE_SLUG`. `SITE_NAME` can be verbose. * Say "This site" (instead of "ICEkit") "is built with ICEkit". * Default ICEkit default/home/sidebar templates are of questionable use, but are kept for now to reduce the amount of required boilerplate just to get something that works. We should be improving our default templates, not removing them. * Use `SLUTE_SLUG` in default `SITE_DOMAIN`, now that we are not rendering a project template, we need sensible defaults for all settings. * Add `_root` suffix to `media` and `static` directories, to avoid conflict level `static` directory and to match up with settings. * Is it safe to use the celery broker URL (Redis DB 0) for cronlock, or should we use a separate database? TBC * Use collected static_root directory as included path for node-sass. * Keep fluent-contents `markup` plugin disabled for now. Seems our forked version is not compatible with Django 1.8. * Combine the old project template root URLconf with the ICEkit app configurable URLs (which it seems we were never using). * Make the hard coded home page URL a fallback. Anticipate adding welcome and getting started content here, instead of adding to the database via data migration. * Add S3 storage classes. * Allow package to be installed without a Git working copy (e.g. inside a Docker container). * Add `manage.py` as a script, so we can run it from anywhere.
* Use bower components for front-end assets that will be collected. The `node_modules` directory is about 17 times larger (not ideal for including in images or packages), and takes longer to install. * Move node modules and bower components into the `icekit` package, for manual installation into a virtualenv. * Don't print that we are still waiting every second. Count the number of seconds we waited and print that when we are done. * Simplify printed docstrings for shell scripts to reduce noise. * Give waitlock.sh sensible default configuration when running outside of Docker, with no configuration in the environment. * Use database result backend for Celery. * Don't use New Relic by default. It was raising an exception, and might be going away soon anyway (pricing). * Rename `/opt/icekit` to `/opt/django-icekit` to match package name. * Install shell scripts from `setup.py`. * Tweak icekit extras installed into Docker image. * Remove goss, since we are not using it yet. * Move files for bundled project to `icekit.project` package, for clarity. * Load local override settings from project, instead of from `local` module in ICEkit settings package. * Move `manage.py` into `icekit` package to trick django-supervisor into being able to locate `supervisord.conf`. * Install `manage.py` as a console entrypoint, so we can run it from anywhere, especially when installing manually from PyPI, so we don't need a `manage.py` script in the project. * Remove default weak master password from development base settings. * Create required project templates directory at runtime. * Use ICEkit base template as project base template by default. * Update setup.py requirements. Remove some Django 1.7 era version restrictions. Add project requirements in an extra. Remove publishing extra - we always want publishing. Add slideshow extra. * Fallback to import `BASE_SETTINGS_MODULE` as a fully qualified dotted path, instead of an ICEkit settings module.
* Only print `BASE_SETTINGS_MODULE` when executing management commands.
…entally create a bunch of subdirectories whenever `manage.py` is run from the wrong location.
…nt.sh`, so let's hide warnings and use a random hash seed again.
…m a working copy.
This reverts commit ab2a90a.
- replace usage of obsolete `PassThroughManagerMixin` from django-model-utils with Django's preferred manager-generating methods - fix "pass-through" of manager method calls so custom queryset methods get invoked when the same method names are called on the corresponding manager (this behaviour got lost due to changes in upstream reqs) - cleanup unused imports and commented-out print statements - add extra req to "test" requirements.
…st for celery flower.
…ke it the default by leaving this out didn't seem to work.
- add publishing middleware to display draft/published items correctly depending on the request context - set `FLUENT_PAGES_PARENT_ADMIN_MIXIN` to properly display only draft items in admin - show publishing status filters in page parent (listing) admin.
Work around infinite recursion issue when using Fluent Pages' Redirects with django-polymorphic>=0.8 by renaming an attribute of the admin class. See django-fluent/django-fluent-pages#110
|
Changes Unknown when pulling 66b4dd0 on feature/project into * on develop*. |
…ng official versions from PyPI instead.
* Don't install our shell scripts with Setuptools. Doing so means we
have to:
* Copy them into the image before we do `pip install -e .` in
`Dockerfile`, so setuptools can install them.
* Reinstall them every time they change during development, to update
the installed version.
* Instead, move our bin directory into the `icekit` package, so it is
included as package data, and is added to `PATH` in `Dockerfile` and
`go.sh`.
* Don't install `manage.py` as a console script. Instead, move it to
`icekit/bin`, and leave an empty file to trick django-supervisor.
|
Changes Unknown when pulling 8822ca9 on feature/project into * on develop*. |
|
Changes Unknown when pulling e7c3190 on feature/project into * on develop*. |
1 similar comment
|
Changes Unknown when pulling e7c3190 on feature/project into * on develop*. |
|
Changes Unknown when pulling 8d01048 on feature/project into * on develop*. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
With this change, we can make ICEkit more like an off the shelf CMS that can be installed and used immediately in its default configuration.
Currently, it is more like a library that must be installed into a new or existing Django project, and we have a separate project template that we use to create new ICEkit projects.
Important things to note:
ixc-project-template(e.g.celery.py,context_processors.py,jinja2.py,urls.py,wsgi.py, etc.) have been added toicekit.project. This is the Django project ICEkit will use by default.startproject.shscript to render it) that is much simpler thanixc-project-templateand includes much less boilerplate code (most of which is now part of ICEkit).go.shentrypoint script that makes running directly work similarly to when running via Docker. Database name is derived from the project directory name and git branch. Bower components, Node modules and Python requirements are updated automatically. Migrations are applied automatically.Deploy to Docker Cloudbutton in the README. You won't be able to customise your project when deploying the official ICEkit Docker image this way, but you can easily get a site wit the default ICEkit configuration and styling.django17-py27, but this and other Django 1.7 environments are no longer tested automatically.django-genericfor one thing, to addSITE_NAMEto the context forRequestContextobjects. Sincedjango-genericisn't on PyPI and I wasn't sure that we should put it on there (it's a fork of DrMeers repo), I removed it instead.DEBUG=Trueand when no Fluent pages exist).Follow the instructions in
README.mdanddocs/contributing.mdto get started.