81–90 of 100 posts
What are people using these days for compiling their static assets (js minification + concatenation, etc)? We have been using django-pipeline but it has been a nightmare.
Why has it been a nightmare? I find it pretty neat. Was using django-compressor earlier but it didn't have support for Python 3.
django-devserver
gargoyle
ipdb
ipython
Earlier quoted context omitted.
Thanks for the tip. Most of it is done by python-dateutil though so I think it in C already. I'm basically checking ~500 recurring events to see if they occur today with django-schedule.
Oooow. Interesting one. So the events can be on different schedules / frequencies? It sounds like something you should be able to do with a single sql query. Could you provide a bit more info?
I'm not certain postgres for example has that kind of functionality around dates. Googling, I found this though:
http://justatheory.com/computers/databases/postgresql/recurring_events.html
I've been away from the Django ecosystem for the last few years.. how is Pinax doing these days?
Earlier quoted context omitted.
Oooow. Interesting one. So the events can be on different schedules / frequencies? It sounds like something you should be able to do with a single sql query. Could you provide a bit more info?
Hmm, currently it uses python-dateutil to find recurring dates. I chose django-schedule at the time as it seemed the best choice, which is built upon it. I'm not certain postgres for example has that kind of functionality around dates. Googling, I found this though: http://justatheory.com/computers/databases/postgresql/recurring_events.html Looks promising. Rewriting the core of the app is a pretty big project though…
If you just needed the events for today you should be able to do something simpler. Depends on the complexity of the frequency controls. But imagine weekly recurring - you should be able to do something like "(today - start day) mod 7 == 0" to find all weekly events that hit today. You could then construct a similar rule for each different frequency:
-- not real code!
select * from event where
(frequency = 'daily')
or (frequency = 'weekly' and (today - starts) % 7 == 0)
or (frequency = 'monthly' and day(today) == day(starts))
or (frequency = ...)
Earlier quoted context omitted.
Close, but not exactly, Andrew Godwin, the creator of South, has added support for migrations into the dev branch of Django, to be part of the Django 1.7 release. https://docs.djangoproject.com/en/dev/topics/migrations/ Andrew has significantly rethought migrations and applied the lessons he's learned from years of maintaining and developing South. He's kept a developer diary that has been pretty fascinating to read…
For a greenfield app, would you recommend starting with 1.7, or do you think it will be simple enough to convert from South that it's not worth it? (I have no idea how stable 1.7 is)
January 20th: 1.7 alpha
March 6th: 1.7 beta
May 1st: 1.7 release candidate
May 15th: Final release (assuming a second release candidate is not needed)
Interesting, my fairly large django project uses none of those. Instead, the addons we consider to be critical are these these: django-debreach django-redis jinja2 pytz Redis for queues and caching, debreach to secure the CSRF tokens and vary your content length to avoid the BREACH vulnerability. jinja2 for doing templates outside of returning data, and pytz so you can use timezones in your data models. I also recomm…
pytz probably doesn't belong in a discussion of Django libraries. It's needed by pretty much any Python program that works with localized datetimes. > jinja2 for doing templates outside of returning data What do you mean?
It's handier and more straight-forward than using Django's templating engine.
Earlier quoted context omitted.
Close, but not exactly, Andrew Godwin, the creator of South, has added support for migrations into the dev branch of Django, to be part of the Django 1.7 release. https://docs.djangoproject.com/en/dev/topics/migrations/ Andrew has significantly rethought migrations and applied the lessons he's learned from years of maintaining and developing South. He's kept a developer diary that has been pretty fascinating to read…
For a greenfield app, would you recommend starting with 1.7, or do you think it will be simple enough to convert from South that it's not worth it? (I have no idea how stable 1.7 is)
You should be fine sticking with South for now.
Earlier quoted context omitted.
pytz probably doesn't belong in a discussion of Django libraries. It's needed by pretty much any Python program that works with localized datetimes. > jinja2 for doing templates outside of returning data What do you mean?
I assume for things like templating emails. Or configuration files for deployment. That's at least what I've used it for. It's handier and more straight-forward than using Django's templating engine.
Earlier quoted context omitted.
I assume for things like templating emails. Or configuration files for deployment. That's at least what I've used it for. It's handier and more straight-forward than using Django's templating engine.
I thought he might have meant that, but I never had too much difficulty doing this through the Django template API.