Deployment with WSGI - Githubissues

yoanisgil commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

"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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

{% 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 commented 10 years ago

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.

iivvoo / django_layers

Deployment with WSGI #4