python-django charm questions

[sheila miguez]

On Tue, Dec 2, 2014 at 11:38 AM, Simon Davy <bloodearnest at gmail.com> wrote:

> On 2 December 2014 at 17:04, sheila miguez <shekay at 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.


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.

-- 
shekay at pobox.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20141202/55aecc2d/attachment.html>