Deployment with WSGI

[yoanisgil]

Hello @iivvoo:

I'm working on a fork of django_layers (https://github.com/yoanis_gil/django_layers) which brings a new feature to the project, that is: the ability to have dynamic layers.

I'm working on this project where websites are dynamic, meaning they are created/removed in an unpredictable manner, but they also need to be skinned/customized as per the client's need.

I kinda have the basics working but I've bumped into a dark area and I would appreciate your help. Can you please let me know how do one deploys django_layers under wsgi? Does it require a particular configuration? I tried to do it myself but the static resources were not being layered (which makes sense since I configured my webserver to server static resources directly from the STATIC_ROOT).

I would appreaciate any help on this matter. For the moment being I will just use Django's web server to serve static content but we both know that's not the recommend approach.

Bests,

Yoanis.

P.D: Let me know if you're interested in including the features I've developed into the project and I will kindly send you a pull request.

Bests,

Yoanis.

[iivvoo]

Hi Yoanis,

In a non-dynamic setup where you define your layers in your settings, you can create per-layer static directories using 'collectlayers'. This is described in the readme.

I don't really see how this could work in a dynamic setup, at least not as long as apache/nginx is responsible for serving staticfiles. You will need a dynamic way to serve then (like django's builtin runserver does) or somehow "dynamically" copy the resources to the static (layer) folder at runtime.

I'll give this some more thought and see if I can come up with something.

And I'd be very interested in a PR once you have something working.

[yoanisgil]

Hello Ivo,

I kinda have something working here:

http://www.arsenlimo.com
http://www.herebygps.com
http://www.rideeze.com

I also modified the collectayers management command to be able to detect dynamic layers and
collect resources. I noticed that everything is placed under STATIC_ROOT/layer_name/. So even
if layers are not dynamic how do django_layers work when the application is deployed using WSGI?
Maybe any idea will be to extend the static_url tag or update the STATIC_ROOT variable to point
to the right layer static folder?

The way I see there is really no difference between dynamic layers and static layers, because I
have introduced the concept of « layer provider » . A layer provider is able to « provide » at any
time the list of available layers. For instance if you take a look at my fork you will see there are
two providers:

• DefaultLayerProvider: This works just as described in the read me and as you originally envision
  it to work.
• ModelLayerProvider: This is a layer provider which is able to retrieve available layers by means
  of loading a list of model instances and creating a dictionary from a given attribute name.

I was hesitant as to whether I should have implemented a new LayerFinder, but to be honest I was
short of time so I hacked AppLayerFinder to update the storage every time a request is done. I know
this is far from optimal but I guess I’ll have to leave with it until I can figure out something better.

Bests,

Yoanis.

Le 2014-04-19 à 02:48 AM, Ivo van der Wijk notifications@github.com a écrit :

Hi Yoanis,

In a non-dynamic setup where you define your laters in your settings, you can create per-layer static directories using 'collectlayers'. This is described in the readme.

I don't really see how this could work in a dynamic setup, at least not as long as apache/nginx is responsible for serving staticfiles. You will need a dynamic way to serve then (like django's builtin runserver does) or somehow "dynamically" copy the resources to the static (layer) folder at runtime.

I'll give this some more thought and see if I can come up with something.

And I'd be very interested in a PR once you have something working.

—
Reply to this email directly or view it on GitHub.

[iivvoo]

"Non-dynamic" layers work because you define in your apache/nginx configuration which folder to use, e.g.

virtualhost_1:
server_name: foo.org
root: /srv/project/static/layer1

virtualhost_2:
server_name: bar.org
root: /srv/project/static/layer2

One of the goals of django_layers is to try to be as unobstructive as possible - code simply depending pn {% static %} should work unchanged since you don't want to/can't change your third party dependencies.

I'll have a look at your fork later and get back to you later.

Ivo

[iivvoo]

One more remark, where django_leyers collects to depends on your LAYERS configuration:

LAYERS = {
    'visitor-a':STATIC_ROOT + '/visitor-a',
    'visitor-b':STATIC_ROOT + '/visitor-b'
    }

will indeed create layer folders under STATIC_ROOT. But you could just as easy define completely distinct folders.

[yoanisgil]

Hello Ivo,

Right up to now I’m using STATIC_URL as the base path to static resources, which clearly does not work on production for django_layers … So, if I get you right
{% static %} will produce the right URL? Right?

Please notice that there is really no much difference between « Non-dynamic « layers and « Dynamic layers » because I’ve encapsulated the logic of pulling
the layers configuration into something I prefer to call « layer provider » .

Please take a look at my fork and let me know what you think … I’ve one or two concerns about performance but right now the ability to have dynamic layers
is far more pressing to me …

Bests,

Yoanis.

Le 2014-04-20 à 04:17 AM, Ivo van der Wijk notifications@github.com a écrit :

"Non-dynamic" layers work because you define in your apache/nginx configuration which folder to use, e.g.

virtualhost_1:
server_name: foo.org
root: /srv/project/static/layer1

virtualhost_2:
server_name: bar.org
root: /srv/project/static/layer2

One of the goals of django_layers is to try to be as unobstructive as possible - code simply depending pn {% static %} should work unchanged since you don't want to/can't change your third party dependencies.

I'll have a look at your fork later and get back to you later.

Ivo

—
Reply to this email directly or view it on GitHub.

[iivvoo]

{% static %} will fill in whatever you have configured as STATIC_ROOT, so {% static "css/foo.css" %} will become /static/css/foo.css

It's up to your front end webserver (apache/nginx) to map this to the appropriate filesystem folder. My example above wasn't fully correct, it's more like

virtualhost_1:
    server_name: foo.org
    alias: /static  /srv/project/static/layer1

virtualhost_2:
    server_name: bar.org
    alias: /static  /srv/somewhere/else/static

This means /static/css/foo.css will go to /srv/project/static/layer1/css/foo.css on virtual_host1 and to /srv/somewhere/else/static/css/foo.css on virtual_host2

Again, it's up to your frontend webserver to correctly map /static somewhere. And of course, collect_layers will copy the resources to these folders based on your LAYERS configuration

[yoanisgil]

I see.

Well, this won’t work for the project I’m working on since sites are created in an un predictable manner and we will like to have
things as automated as possible. I’m probably going to go with the option of modifying STATIC_URL or the static tag. I will figure
out a way that’s the less intrusive it could be (I totally agree with the approach you took about django_layers being non-intrusive).

Bests,

Yoanis.

Le 2014-04-21 à 04:18 AM, Ivo van der Wijk notifications@github.com a écrit :

{% static %} will fill in whatever you have configured as STATIC_ROOT, so {% static "css/foo.css" %} will become /static/css/foo.css

It's up to your front end webserver (apache/nginx) to map this to the appropriate filesystem folder. My example above wasn't fully correct, it's more like

virtualhost_1:
server_name: foo.org
alias: /static /srv/project/static/layer1

virtualhost_2:
server_name: bar.org
alias: /static /srv/somewhere/else/static
This means /static/css/foo.css will go to /srv/project/static/layer1/css/foo.css on virtual_host1 and to /srv/somewhere/else/static/css/foo.css on virtual_host2

Again, it's up to your frontend webserver to correctly map /static somewhere. And of course, collect_layers will copy the resources to these folders based on your LAYERS configuration

—
Reply to this email directly or view it on GitHub.