librelist archives

« back to archive

Some help with common conventions

Some help with common conventions

From:
Mark Grey
Date:
2012-11-07 @ 16:58
Hey all,

I apologize if this is a long message, but I was looking for some insights
on some things in Flask that I still haven't settled into a convention for
yet.  If I could get some idea what the most common approach is to some of
these problems it would really help me out with app development with Flask.
 Any insight is appreciated.

1.  Default subdomains

I understand the SERVER_NAME config directive and how this is used to sniff
out subdomains and why this is a problem both within the browser and on the
server side.  What I don't get is the most common approach to deploying the
same WSGI instance at both the 'www' subdomain as well as the domain alone
('www.something.com' as well as 'something.com'), which has got to be a
pretty common use case.  I get that this is usually a decision to be made
at the webserver level, but how do I make a Flask app expect to answer
requests for either.

Currently, I write one `base` Blueprint and attach it with
`register_blueprint` twice with the kwarg `subdomain` set to both 'www' and
None.  Is this the best approach?  We Twisted.web for our server, and this
generally works for deployment, I'm just curious how most of you solve this
very common problem.

2.  Config swapping

Generally, an app will have a testing configuration and a production one.
 I do this as is recommended in the docs, using object inheritance.  I put
a `config.py` file in the app directory and then import it into the app and
use `.from_object` to set it up on the instance.

I usually use `socket.gethostname()` to check the machine hostname to
automate whether or not to use production or testing config.  There must be
a better way of doing this, though.  I am wondering how you guys manage
your separate configurations and where in the app instantiation you
automate the selection process.  Is it a part of the `create_app` function
that usually returns the wsgi instance?

Also, is it smart to have a separate config file like I do?

3.  Apps as packages

Right now I have a directory structure that looks something like this:

+project_name
  -__init__.py
  -wsgi_app.py
  -config.py

Generally this is a starting point.  The whole app is then a python
package, and in some cases, additional packages and modules are included
inside in more complex projects.  For some reason, this is how I've
understood organizing a project for as long as I've used Flask.

I often have the problem of having to adjust the pythonpath to get the app
as a local instance for our other devs.  This can be a PITA at times.  Do
you guys make your apps packages?

Also, some of the subpackages need access to config directives, especially
when I have a `models` package.  Is it ok to import the configuration
directly?  Wouldn't this mean the automation from question 2 would have to
be built into the config.py file?

/questions

Thanks for any help.  I realize a great deal of what I'm asking is
preference-based, but it would be really great to know what emerges as the
best practice.

~Mark

Re: [flask] Some help with common conventions

From:
Jeffrey Tratner
Date:
2012-11-08 @ 00:07
on your problem with pythonpaths: why can't each person use a copy of the
app and then run it from the parent directory?

By the way, usually I end up structuring my Python apps more like this, so
I can store some files in the code directory and others elsewhere (no idea
if you are already doing this):

myapp/
    myapp/
        -__init__.py
        -other_python_files.py
    test/
    docs/

etc...Then, all you need to do is to cd into the outer directory and your
app will be automatically in the python path for the project. Sometimes I
also set up a Makefile to run the app or use it in the console, to make it
dead simple to use.

As for application settings,  I like how Mozilla sets their settingsin
their Playdoh skeleton for Django: they use a single settings.py file that
they always point to in production and testing, but the file imports first
from a base_settings.py and then a local_settings.py, allowing them to
overwrite whatever they like for the current production environment.


On Wed, Nov 7, 2012 at 11:58 AM, Mark Grey <mark.asperia@gmail.com> wrote:

> Hey all,
>
> I apologize if this is a long message, but I was looking for some insights
> on some things in Flask that I still haven't settled into a convention for
> yet.  If I could get some idea what the most common approach is to some of
> these problems it would really help me out with app development with Flask.
>  Any insight is appreciated.
>
> 1.  Default subdomains
>
> I understand the SERVER_NAME config directive and how this is used to
> sniff out subdomains and why this is a problem both within the browser and
> on the server side.  What I don't get is the most common approach to
> deploying the same WSGI instance at both the 'www' subdomain as well as the
> domain alone ('www.something.com' as well as 'something.com'), which has
> got to be a pretty common use case.  I get that this is usually a decision
> to be made at the webserver level, but how do I make a Flask app expect to
> answer requests for either.
>
> Currently, I write one `base` Blueprint and attach it with
> `register_blueprint` twice with the kwarg `subdomain` set to both 'www' and
> None.  Is this the best approach?  We Twisted.web for our server, and this
> generally works for deployment, I'm just curious how most of you solve this
> very common problem.
>
> 2.  Config swapping
>
> Generally, an app will have a testing configuration and a production one.
>  I do this as is recommended in the docs, using object inheritance.  I put
> a `config.py` file in the app directory and then import it into the app and
> use `.from_object` to set it up on the instance.
>
> I usually use `socket.gethostname()` to check the machine hostname to
> automate whether or not to use production or testing config.  There must be
> a better way of doing this, though.  I am wondering how you guys manage
> your separate configurations and where in the app instantiation you
> automate the selection process.  Is it a part of the `create_app` function
> that usually returns the wsgi instance?
>
> Also, is it smart to have a separate config file like I do?
>
> 3.  Apps as packages
>
> Right now I have a directory structure that looks something like this:
>
> +project_name
>   -__init__.py
>   -wsgi_app.py
>   -config.py
>
> Generally this is a starting point.  The whole app is then a python
> package, and in some cases, additional packages and modules are included
> inside in more complex projects.  For some reason, this is how I've
> understood organizing a project for as long as I've used Flask.
>
> I often have the problem of having to adjust the pythonpath to get the app
> as a local instance for our other devs.  This can be a PITA at times.  Do
> you guys make your apps packages?
>
> Also, some of the subpackages need access to config directives, especially
> when I have a `models` package.  Is it ok to import the configuration
> directly?  Wouldn't this mean the automation from question 2 would have to
> be built into the config.py file?
>
> /questions
>
> Thanks for any help.  I realize a great deal of what I'm asking is
> preference-based, but it would be really great to know what emerges as the
> best practice.
>
> ~Mark
>

Re: [flask] Some help with common conventions

From:
Audrius Kažukauskas
Date:
2012-11-14 @ 11:41
On Wed, 2012-11-07 at 11:58:05 -0500, Mark Grey wrote:
> 1.  Default subdomains
> 
> I understand the SERVER_NAME config directive and how this is used to sniff
> out subdomains and why this is a problem both within the browser and on the
> server side.  What I don't get is the most common approach to deploying the
> same WSGI instance at both the 'www' subdomain as well as the domain alone
> ('www.something.com' as well as 'something.com'), which has got to be a
> pretty common use case.  I get that this is usually a decision to be made
> at the webserver level, but how do I make a Flask app expect to answer
> requests for either.

You should choose which domain (with www. or without it) will be the
main one and configure your web server to redirect all URLs from one to
the other.  No need to handle this at your webapp.  This will also help
your website in regard to SEO (single URL pointing at the same resource
instead of two).

> 2.  Config swapping
> 
> I usually use `socket.gethostname()` to check the machine hostname to
> automate whether or not to use production or testing config.  There must be
> a better way of doing this, though.  I am wondering how you guys manage
> your separate configurations and where in the app instantiation you
> automate the selection process.  Is it a part of the `create_app` function
> that usually returns the wsgi instance?
> 
> Also, is it smart to have a separate config file like I do?

I usually set up my webapps to have a default config which could be
overriden by environment variable:

  app.config.from_envvar('MYAPP_CONF', silent=True)

When deploying the app to uWSGI server, the envvar is set in its
configuration:

  [uwsgi]
  ...
  env = MYAPP_CONF=%d/config.py
  ...

%d is an absolute path to the directory containing the uWSGI config
file.  The value is provided by uWSGI Emperor, not sure if it will work
in a single instance mode.

> 3.  Apps as packages
> 
> I often have the problem of having to adjust the pythonpath to get the app
> as a local instance for our other devs.  This can be a PITA at times.  Do
> you guys make your apps packages?

As another poster already noted, I usually structure my projects like
this:

  project/
    project/
      __init__.py
      ...
    tests/
    ...

> Also, some of the subpackages need access to config directives, especially
> when I have a `models` package.  Is it ok to import the configuration
> directly?  Wouldn't this mean the automation from question 2 would have to
> be built into the config.py file?

In this case configuration could be accessed via current_app proxy:

  from flask import current_app
  current_app.config['FOOBAR']

-- 
Audrius Kažukauskas
http://neutrino.lt/