5 ms·

Cool. My "always on" Django apps: * django-compressor * django-debug-toolbar * django-waffle * django-jenkins * django-statsd-mozilla * django-mar

Cool. My "always on" Django apps: * django-compressor * django-debug-toolbar * django-waffle * django-jenkins * django-statsd-mozilla * django-markwhat * django-storages (to put static assets on S3/Cloudfront) * django-smoketest Frequent additions as needed: * django-bootstrap3 * django-rest-framework * django-filter * celery * wagtail I used to use django-extensions everywhere, but it pulls in ipython and all of ipython's dependencies, which gets pretty heavy.

nsomaru 9y ago
Would love to know your thoughts on wagtail? I've been evaluating it (as against django cms mostly), but resources seem generally scarce - there's no big irc channel, the mailing list directs you to SO, and SO doesn't seem particularly active on the wagtail front either. So where do you go for help or if you need to bounce something off someone more experienced in Wagtail than yourself? Streamfield looks great! It seems a perfect replacement to my rigid model-per-content-type approach. Wagtail's deviation from standard Django patterns (no views!) are a little concerning too.
- tomd 9y ago
  I'm one of the Wagtail core developers. We made the mistake of spreading our support across too many channels (Google Groups, Stack Overflow, IRC, semi-private Slack) but we've made a clear decision to focus on Stack Overflow for developer-related questions: https://stackoverflow.com/questions/tagged/wagtail https://stackoverflow.com/questions/tagged/wagtail mainly as a result of this poll: https://twitter.com/WagtailCMS/status/801384753589080064 https://twitter.com/WagtailCMS/status/801384753589080064 Please feel free to contact me directly (details in profile) if you're not getting the support you need on SO.
- thraxil 9y ago
  Yeah, Wagtail documentation is a bit scattered. That's probably one of the larger issues I've run into when using it. Overall, I like it though. As much as it seems like a deviation from Django patterns, I actually found it easier to integrate Wagtail into existing Django projects than others like django-cms. I find that I typically end up with a "CMS" part of the app that exists fairly independently from the rest. Making foreign-key references to models outside Wagtail isn't too hard, and it integrates fine with the main site templates. Otherwise, I find that I don't often need to do much interaction between the Wagtail parts and other parts (which would be hard). I haven't really done a lot of complicated things with Wagtail though.
- spapas82 9y ago
  Wagtail has a good tutorial to get you started (http://docs.wagtail.io/en/latest/getting_started/tutorial.html http://docs.wagtail.io/en/latest/getting_started/tutorial.ht...) and has good enough documentation (that I think would need some improvements). I know it seems a bit overwhelming to start a new project but you can try to learn from existing ones that are available for example the good-old wagtaildemo: https://github.com/wagtail/wagtaildemo https://github.com/wagtail/wagtaildemo, the better-wagtail-demo: https://github.com/wagtail/bakerydemo https://github.com/wagtail/bakerydemo and of course the RCA (https://www.rca.ac.uk https://www.rca.ac.uk) website https://github.com/torchbox/verdant-rca/ https://github.com/torchbox/verdant-rca/ (be careful this is a huge project that uses a little old version of wagtail - 1.6 but most base things are the same in later versions) Now, for answering your questions I think that Stackoverflow should be fine for asking, most (if not all) questions are answered there (I know that most wagtail developers monitor SO for new questions and answer them promptly). Don't be discouraged by the small volume of questions -- the only problem with SO is that some questions (the more open ones, for example those discussing architecture) are not considered proper for this site and are closed so you should use the mailing list for that. For the StreamField I totally agree that it rocks however keep in mind that you'll still need to add a model-per-content-type (maybe not so many content types but you will definitely need more than one content type) - I think that the StreamField offers more freedom to the hands of the content editors, using it they can mix and match their content to the page and not follow specific patterns that the developers have decided. Finally, concerning the deviation from views, don't be alarmed. Wagtail uses a concept called Page (probably should've been called PageType or WagtailContentType but anyway) which is a mixture between a Model and a class based view. So you create your own subclass of pages which are Articles, NewsItems, Events etc. The important thing is that most functionality of CBVs is inherited when serving each Page type so you can override the various class methods like get_context (to add specific things to the context of a page), get_template (to change the template of a page type), serve (to have full control on serving the page) etc. Also you can add mixins similar to CBVs so that many of your Pages will share some functionality. I recommend you try wagtail and I think that you'll like it!
spapas82 9y ago
Interesting list - we have a lot in common (however I prefer rq vs celery because of ease of installation and configuration) For django-extensions are you sure about ipython? I install it with pip install django-extensions and nothing else is installed. Ipython will be used if found, if not it will fallback to the default python shell (it also supports bpython and ptpython: http://django-extensions.readthedocs.io/en/latest/shell_plus.html http://django-extensions.readthedocs.io/en/latest/shell_plus...). I wasn't aware of django-smoketest - seems like a nice addition to my deploy workflow!
- thraxil 9y ago
  Is it actually worth using shell_plus without ipython though? If I was starting from scratch, I'd take a closer look at django-rq. I've used celery for years though and have more experience running RabbitMQ than Redis, so it's the devil I know. I wrote django-smoketest originally, so I'm a bit biased, but I can't count how many problems it's caught for me early on. A related blog post I wrote last year: https://compiled.ctl.columbia.edu/articles/smoketesting-for-health/ https://compiled.ctl.columbia.edu/articles/smoketesting-for-...
  - spapas82 9y ago
    For me yes, using shell_plus even with the plain old python shell is worth it because it automagically imports most of the things you are going to need and saves you a lot of keystrokes (it imports all your models and some things from django, most notably settings so you don't need to do a 'from django.conf import settings'). Also, as I have already mentioned in the article, the killer feature of django-extensions (for me) is the runserver_plus and its integration with the Werkzeug debugger - just add an exception somewhere in your app and you'll get a full python shell. I would definitely consider (and probably use) celery for an application with heavy task usage (or if I had the need for its more advanced capabilities) - definitely using a proper message queue like RabbitMQ should have better behavior than Redis, however django-rq covers all my needs till now so that's what I have included in the list and use in my day to day projects. After all, redis is much more popular than RabbitMQ and can be used for other purposes beyond asynchronous tasks (for example you can use redis for caching instead of memcached and also django-constance uses redis to save settings). Thanks for the article, it confirms that django-smoketest is something I need use to my new proejcts and probably integrate it to old projects with a lot of moving parts!

nsomaru 9y ago

Would love to know your thoughts on wagtail? I've been evaluating it (as against django cms mostly), but resources seem generally scarce - there's no big irc channel, the mailing list directs you to SO, and SO doesn't seem particularly active on the wagtail front either. So where do you go for help or if you need to bounce something off someone more experienced in Wagtail than yourself? Streamfield looks great! It seems a perfect replacement to my rigid model-per-content-type approach. Wagtail's deviation from standard Django patterns (no views!) are a little concerning too.

tomd 9y ago
I'm one of the Wagtail core developers. We made the mistake of spreading our support across too many channels (Google Groups, Stack Overflow, IRC, semi-private Slack) but we've made a clear decision to focus on Stack Overflow for developer-related questions: https://stackoverflow.com/questions/tagged/wagtail https://stackoverflow.com/questions/tagged/wagtail mainly as a result of this poll: https://twitter.com/WagtailCMS/status/801384753589080064 https://twitter.com/WagtailCMS/status/801384753589080064 Please feel free to contact me directly (details in profile) if you're not getting the support you need on SO.
thraxil 9y ago
Yeah, Wagtail documentation is a bit scattered. That's probably one of the larger issues I've run into when using it. Overall, I like it though. As much as it seems like a deviation from Django patterns, I actually found it easier to integrate Wagtail into existing Django projects than others like django-cms. I find that I typically end up with a "CMS" part of the app that exists fairly independently from the rest. Making foreign-key references to models outside Wagtail isn't too hard, and it integrates fine with the main site templates. Otherwise, I find that I don't often need to do much interaction between the Wagtail parts and other parts (which would be hard). I haven't really done a lot of complicated things with Wagtail though.
spapas82 9y ago
Wagtail has a good tutorial to get you started (http://docs.wagtail.io/en/latest/getting_started/tutorial.html http://docs.wagtail.io/en/latest/getting_started/tutorial.ht...) and has good enough documentation (that I think would need some improvements). I know it seems a bit overwhelming to start a new project but you can try to learn from existing ones that are available for example the good-old wagtaildemo: https://github.com/wagtail/wagtaildemo https://github.com/wagtail/wagtaildemo, the better-wagtail-demo: https://github.com/wagtail/bakerydemo https://github.com/wagtail/bakerydemo and of course the RCA (https://www.rca.ac.uk https://www.rca.ac.uk) website https://github.com/torchbox/verdant-rca/ https://github.com/torchbox/verdant-rca/ (be careful this is a huge project that uses a little old version of wagtail - 1.6 but most base things are the same in later versions) Now, for answering your questions I think that Stackoverflow should be fine for asking, most (if not all) questions are answered there (I know that most wagtail developers monitor SO for new questions and answer them promptly). Don't be discouraged by the small volume of questions -- the only problem with SO is that some questions (the more open ones, for example those discussing architecture) are not considered proper for this site and are closed so you should use the mailing list for that. For the StreamField I totally agree that it rocks however keep in mind that you'll still need to add a model-per-content-type (maybe not so many content types but you will definitely need more than one content type) - I think that the StreamField offers more freedom to the hands of the content editors, using it they can mix and match their content to the page and not follow specific patterns that the developers have decided. Finally, concerning the deviation from views, don't be alarmed. Wagtail uses a concept called Page (probably should've been called PageType or WagtailContentType but anyway) which is a mixture between a Model and a class based view. So you create your own subclass of pages which are Articles, NewsItems, Events etc. The important thing is that most functionality of CBVs is inherited when serving each Page type so you can override the various class methods like get_context (to add specific things to the context of a page), get_template (to change the template of a page type), serve (to have full control on serving the page) etc. Also you can add mixins similar to CBVs so that many of your Pages will share some functionality. I recommend you try wagtail and I think that you'll like it!

spapas82 9y ago

Interesting list - we have a lot in common (however I prefer rq vs celery because of ease of installation and configuration) For django-extensions are you sure about ipython? I install it with pip install django-extensions and nothing else is installed. Ipython will be used if found, if not it will fallback to the default python shell (it also supports bpython and ptpython: http://django-extensions.readthedocs.io/en/latest/shell_plus.html http://django-extensions.readthedocs.io/en/latest/shell_plus...). I wasn't aware of django-smoketest - seems like a nice addition to my deploy workflow!

thraxil 9y ago
Is it actually worth using shell_plus without ipython though? If I was starting from scratch, I'd take a closer look at django-rq. I've used celery for years though and have more experience running RabbitMQ than Redis, so it's the devil I know. I wrote django-smoketest originally, so I'm a bit biased, but I can't count how many problems it's caught for me early on. A related blog post I wrote last year: https://compiled.ctl.columbia.edu/articles/smoketesting-for-health/ https://compiled.ctl.columbia.edu/articles/smoketesting-for-...
- spapas82 9y ago
  For me yes, using shell_plus even with the plain old python shell is worth it because it automagically imports most of the things you are going to need and saves you a lot of keystrokes (it imports all your models and some things from django, most notably settings so you don't need to do a 'from django.conf import settings'). Also, as I have already mentioned in the article, the killer feature of django-extensions (for me) is the runserver_plus and its integration with the Werkzeug debugger - just add an exception somewhere in your app and you'll get a full python shell. I would definitely consider (and probably use) celery for an application with heavy task usage (or if I had the need for its more advanced capabilities) - definitely using a proper message queue like RabbitMQ should have better behavior than Redis, however django-rq covers all my needs till now so that's what I have included in the list and use in my day to day projects. After all, redis is much more popular than RabbitMQ and can be used for other purposes beyond asynchronous tasks (for example you can use redis for caching instead of memcached and also django-constance uses redis to save settings). Thanks for the article, it confirms that django-smoketest is something I need use to my new proejcts and probably integrate it to old projects with a lot of moving parts!