On Thu, Sep 25, 2014 at 07:06:51PM +0100, Evan Dandrea wrote: > On 25 September 2014 14:43, Joe Talbott <[email protected]> wrote: > > 1. We have several places in webui/webui/settings.py where we're blindly > > doing this: > > > > path = os.path.join(BASE_DIR, '../../../../allowed_host.json') > > > > This is of course bad since it's assuming the app is installed in the > > manner we deploy. > > > > I'm not sure how we can get around this and make IS happy. One approach > > I've seen used is to have symlinks for these external data files and > > local settings files. We'd need to handle the situation where those > > files are absent as well and our current try/except logic might work for > > that. Thoughts? > > Let's follow the required IS Prodstack policy and put all config data > under /srv/.../etc, and all variable data under /srv/.../var: > > https://wiki.canonical.com/InformationInfrastructure/IS/Policies/Prodstack#You_Must: > > As you point out, this precludes the relative path approach, since we > absolutely cannot assume any part of the path name. Instead, I think > we should have the charm write out templates with absolute paths built > from the config.yaml data (service name, etc).
Thanks for your response. That's a fine approach but where do we put that template? I don't think we can make settings.py a template since then the charm is altering code in the payload. We already support a 'local_settings.py' file in the branch and could have the charm populate that with the required info, i.e. paths to config and variable data. > > > 2. We have a couple of places in ticket-system/ticket_system/settings.py > > where we are using 'print'. I think this is bad as well. I have a > > patch that removes two 'print' calls that seem to be debugging info and > > converts another, which is a proper warning, to output to stderr. The > > reason I'm bringing this up is for the client credential creation I have > > a management command (manage.py create_client <redirect_uri>) that is > > expected to, upon success, output the client credentials to give to the > > other end of the relationship. Thoughts? > > +1 > > I believe that print makes sense only in the context of reporting back > to the user of a CLI. Why not also send the warning to the log instead > of stderr? It's my (perhaps misguided) impression that logging in settings.py is bad as well as logging something before logging is configured prevents later basicConfig() calls from having an effect. The docs say that basicConfig is only for simple scripts so perhaps I'm being overly cautious. Does anyone have any experience or knowledge regarding logging in a django settings.py file? Joe -- Mailing list: https://launchpad.net/~canonical-ci-engineering Post to : [email protected] Unsubscribe : https://launchpad.net/~canonical-ci-engineering More help : https://help.launchpad.net/ListHelp
