On Tue, Dec 2, 2014 at 11:38 AM, Simon Davy <[email protected]> wrote:
> On 2 December 2014 at 17:04, sheila miguez <[email protected]> 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. Cool! I will make a MR when the pure-python branch lands. I'll probably pop up in #juju if I can't figure out how to test charms properly before asking for review. > > 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. This makes sense. I went with dj-static too, but figured people might want to have the option not to. I can hold back making a MR for this in case it is not in line with the project goals. > > * 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 > [more on subordinate charming] This makes more sense than my changes to add tgz. I used the charm that way based on ignorance. > * 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. I need to double check my assumptions. Patrick mentioned a case where it shouldn't fail, but I'm questioning that. I'll trace through the charm carefully before making a MR here. > 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? > No, I made a mistake and committed it to a private team when it doesn't have any private information. Sorry about that. > Which apache2 template are you referring to? One in your fork, or the > apache charm? > The apache charm in the charm store. > > 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. I bet this is a user error on my part. > > * Why is django_extra_settings used in config_changed but not during > > install? > > I expect that's a bug. I can look in to it and make a MR when I have a chance. This might take me longer than doing the others. Thanks very much for the answers! The channel and the mailing list have been great. -- [email protected]
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
