On 2 December 2014 at 17:04, sheila miguez <she...@pobox.com> wrote: > Hi all, > > > Pip wishes > > * pip_extra_args support so that I can use --no-index > --find-links=/path/to/wheels (this is in my fork) > * remove --upgrade --use-mirrors, leave it up to the user (in my fork)
First class support for wheels in the charm would be good. > Django wishes > > * call collectstatic (in my fork). I see a pending MR with something like > this, but it enforces dj-static, which I would not do. Right, I think this is my branch, which was to get a demo working. Although, we do use dj-static in prod (with squid in front) and it works great, same solution in dev/prod, and fast (assuming squid or similar). AIUI, th alternatives are to a) deploy to alt service (cdn, apache, whatever), which means deploying to two targets, which I prefer not to do, or b) running apache/nginx on the django units to serve. But, in our deployments, static assets are always accelerated by squid or similar, so there's not much benefit to b. > * allow installing from tgz (in my fork) So, the django charm allows more extensive customisation via a subordinate charm. This means you can write your own subordinate charm, bundle/fetch your tgz as appropriate, control your own settings.py, etc. You relate it to the django charm, and it supplies the needed info to the django charm, which will do the rest. I think this is generally a good route to go, as a single django charm cannot reasonably support every deployment option under the sun. That being said, I haven't personally used this feature, not am I the maintainer, so Patrick may have more to add, or correct me. > * fail on install/config changed if django-admin.py is not found. discovered > this doesn't happen when it isn't installed, while working on the pip > changes. otherwise it fails (in my fork) Yeah, failing hard with good logs is always good. > * allow users to inject custom templates. e.g. conditionally add > django-debug-toolbar based on DEBUG. You mean settings.py templates? You can do that with the custom subordiate above. > Newbie Questions > > * My fork adds a couple of lines to website_relation_joined_changed because > the unit_name and port were not available to populate my apache2 template > otherwise, but this could be due to user error. How do other people do this? Is your fork available to view? Which apache2 template are you referring to? One in your fork, or the apache charm? This sounds odd, as the http relation type should expose 'port' and 'hostname' variables, with hostname usually defaulting to the unit name. When I've used the django charm, this worked as expected. > * Why is django_extra_settings used in config_changed but not during > install? I expect that's a bug. -- Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
