working with ./mange.py runserver but not with uwsgi

[toranb]

working with ./mange.py runserver but not with uwsgi

[toranb]

Interesting, first question off the top -can you ssh to your test or production server (the machine using uwsgi in this case I assume) and manually kick off a precompile using node for a handelbars template you have? What version of node is running on this machine?

Or are you running uwsgi on the same developer machine you use to run it with the simple runserver?

[abarax]

Hi Toran, Thanks so much for your reply! I really appreciate it.

Versions:
Python: 2.7.3
Node: 0.10.24

Manual compile of individual ember templates works fine.

This is an ec2 instance I am using for development.

I believe I can get around the issue by using the compressor's ./manage compress utility and turning off compressor in the settings file but this is not ideal.

I just thought it might lead to a bug either in this plugin or django_compressor itself. Somehow the interaction with uwsgi is breaking the automatic compression.

Do you know what mod_name is supposed to evaluate to in this code?

mod_name, cls_name = get_mod_func(filter_or_command)

Given that 'filter_or_command' is this './node_modules/django-ember-precompile/bin/django-ember-precompile {infile}' and get_mod_func returns this:

return callback[:dot], callback[dot + 1:]

It makes me wonder how the compression worked in the first place using a regular ./manage.py runserver

Thanks again!

[toranb]

Thanks for the extreme detail but honestly the npm module doesn't do anything but invoke a line of javascript

//takes the template {{unbound propertyName}} and invokes precompile with it
var input = compiler.precompile(template['content']);

This looks like something inside compressor (but again -just a guess). I wish I knew more about django compressor but honestly I haven't been inside the internals and since switched to grunt for my production builds.

Sorry I can't offer more insight but my lack of experience w/ compressor is the issue here

[abarax]

Yeah I know, thanks a lot for taking the time to reply. Our plan is to switch to grunt as well but being the early phase of a business we just don't have the time at the moment, there's one hundred other priorities.

The workaround is good enough, I just run ./manage compress and turn off the dynamic compression in my settings.

The issue is most certainly not with the node module. Its the interaction between it and the compressor, we'll just chalk it up to an anomoly and maybe someone will find this correspondance useful and/or switch to grunt as a priority.

Thanks again.

Thank a lot for the help..

[toranb]

How complicated are your grunt needs? is the app multi-paged or single(ish) paged? are you building css and js? how will you / do you deploy this django app today?

[abarax]

Its a single page app built with ember.js and a django-rest-framework backend. I dont imagine they will be that complicated. The only reason i stuck with django handling this stuff was because it was easy to get working without a massive amount of up front work. Deployment is largely manual at this point but I plan to change that when I get the time.

[toranb]

No worries -I just wanted to lend a hand if I could help out. I have a fairly basic grunt script I could walk you through that does the job for local dev + deployment (including a special hashed js filename to bust the cache when you deploy new client side code). Let me know if you decide to switch it up in the future toranb [at] gmail