6 ms·
12. Use `pip freeze` to keep a list of your requirements, and keep that requirements list in your repo. Use virtualenv and virtualenvwrapper to keep your enviro
by streblo 14y ago
12. Use `pip freeze` to keep a list of your requirements, and keep that requirements list in your repo. Use virtualenv and virtualenvwrapper to keep your environment clean from other environments. Virtualenvburrito (https://github.com/brainsik/virtualenv-burrito https://github.com/brainsik/virtualenv-burrito) will help you set it all up.
13. You almost never need to write bash scripts. Use django management commands to write scripts that interact with your application. Use fabric and a fabfile to do deploys. Use something like chef or puppet to do machine configuration. Your bin/ folder will turn into an unmaintainable mess very quickly.
14. Use south. Yes, it's obtuse, but it gets the job done.
15. Use a pre_save hook on all of your models to do full_clean for validation before anything goes to the database. This will save you from cleaning up your data later.
from django.db.models.signals import pre_save
def validate_model(sender, **kwargs):
if 'raw' in kwargs and not kwargs['raw']:
kwargs['instance'].full_clean()
pre_save.connect(validate_model, dispatch_uid='validate_models')
16. If you're writing a javascript-heavy application, consider all of your options for static asset management before you get too deep. I've used django-compressor, django-pipeline, webassets, and django-gears. None of them are perfect solutions (there still isn't a sprockets-esque one-catch-all solution for django like in the rails world), so consider the pros and cons before you make a choice.
edited for formatting
- deleted 14y ago[deleted]
- Bockit 14y agoWould you mind expanding on the issues you have with pipeline? I use pipeline at the moment and beyond a couple of small things (mainly working with vendor apps) I'm really happy with it, but I'm open to the idea that it's because of what I don't know than because it solves every problem.
- streblo 14y agoMostly with setup and configuration. Configuring it to work the way I expected required a lot of digging through documentation/code/blogs/fudging around. I don't like it when I have to do that, for a number of reasons -- a. I'm lazy and I don't like spending a lot of time doing upfront configuration, b. when something doesn't come with sensible defaults pre-configured, I assume I'll do something wrong and it'll have non-obvious but bad consequences. I had this problem with django-compressor as well (but more with configuring 3rd party asset compilation). I usually recommend people use webassets via django-assets. It's easy to configure and very feature-ful.
- elithrar 14y ago> (there still isn't a sprockets-esque one-catch-all solution for django like in the rails world) This is definitely a little frustrating. I'd kill for a solution that handles minification, versioning & can upload to S3/etc. You can pass things through boto to get to s3, but the rest requires a bit of fiddling. I've seen a few solutions that come close, but then they have extremely odd versioning systems. I should just fork something so I can add an ISO8601 timestamp to my CSS & JS; which I like because having granular dates helps when debugging front-end issues.
- jdunck 14y ago> I'd kill for a solution Would you code for one? I, too, am sorry that we don't have a thing like asset pipeline. I'm pretty sure it would be welcome...
- kevinastone 14y agoWhat have you tried? Because staticfiles + django-storages + django-compressor sounds like it can handle that use case.
- th 14y agoI'm using exactly that setup and it does work, it just took me many hours and over 100 lines of custom storages + settings code to get it working. I had to solve issues with custom domains, HTTPS, gzip, separate media/static files buckets, and storages/compressor not playing nicely together in general.
- ritchiea 14y agoI have been developing with rails for a couple years, though I am comfortable with python I've never touched django because I haven't had to and one thing I will say is that the rails asset pipeline documentation is something I constantly return to. The asset pipeline provides a lot of functionality but not a lot of simplicity or management of complexity. If what you wish you had from rails is the asset pipeline you are either either an expert with with rails api or you are seeing things greener on the other side of the fence. I don't mean to insult the asset pipeline, it provides a lot. But it definitely doesn't save you hours. Out of the box the asset pipeline is great for all the things that come for free but if you are doing a lot of development in the framework you probably return to the asset pipeline documentation on a regular basis. And I consider time spent in documentation a negative compared to time finding your own solution if the API is not intuitive and you find yourself consistently returning to the docs about similar problems. And let me tell you, plenty of my fellow Rails devs have said to me they also regularly return to the asset pipeline docs.
- jdunck 14y agoRegarding 15 - if you want that behavior, you'd be better off with using your own model subclass: class ValidatingModel(Model): def save(self, *args, **kwargs): self.full_clean() super(ValidatingModel, self).save(*args, **kwargs) Then inherit from that everywhere. Signals have a not-insignificant overhead. They are most useful for tying together code that comes from different places. (If you want to do full validations on 3rd-party app models, then you might this signal approach, but it might also be a bug in the app that the hook isn't just there for you.)
- windexh8er 14y agoI'd maybe also suggest pythonbrew since you win by getting the exact version of Python you want and virtualenv is packaged up nice with it.
- emddudley 14y ago> Virtualenvburrito will help you set it all up. Is it just me, or is it a little absurd to have a wrapper for a wrapper to a Python module?
- zwass 14y agoI think the author recognizes that as well, hence the name.
- amccloud 14y agopip freeze has always been horrible for me. I've been better off managing my requirements manually.
- Spiritus 14y agoAt least managing multiple files is a pain. I've had to resort to $ vimdiff <(pip freeze) requirements/prod.txt You can't just do "pip freeze > requirements.txt" like you see on every tutorial. I wish there was a better way to do this. And I would also like to only display without dependencies. Say I "pip install X", which depends on Y and Z as well. Then later I want to delete X, so I just "pip uninstall X", but I will still have Y and Z.
- tracker1 14y agoJust responding to #16, it may be best to manage your static/client assets using NodeJS with grunt... It's not in the django chain, but may be worth calling the external. Node seems to be at the leading edge of JS & CSS tooling. It's worth noting that I'm a pretty big NodeJS fan and am even using grunt via node for building the client bits in my latest .Net project at work. It's pretty sweet, though some addons are broken since the new grunt version.
- crucialfelix 14y agoI've switched to this method as well and recently removed django-compressor. Better to have a tool that is used and improved by many, not just django people. In the top level of my project I have a makefile so make assets runs grunt and collects static. My grunt also runs jslint so it will halt if there are errors.
- andrewthornton 14y agoWould you mind giving a little more of an overview of how you set this up? I think this would be incredibly useful.
- crucialfelix 14y agoI'm going to try to throw together a blog post. basically though, I've used requirejs for the js both for single page apps and for general js like plugins and galleries. compass/sass for the css which does minification and concatenation already, and also ensures there is no illegal css js is processed by requirejs into STATIC_DIR/r/ css is compiled into myproject/static/myproject/css and then uses django's staticfiles system to collect and deploy grunt is what calls requirejs. it could also concat and minimize css but compass has already done it. it also has watch and does live reload so that my browser will reload the css and even the js when either of them are edited. on my pages I use a tag: {% vcss "nestseekers/css/front.css" %} which renders a <link css tag with a ?v=HASH appended and {% r_url 'nestseekers/js/libs/dist/html5shiv.js' %} for the js
- flexterra 14y ago#16 is one of the biggest pains we had to deal with but I think we now have a good solution for now. We use brunch.io a node.js build tool. It handles concatenation and minification of CoffeeScript, Stylus and Handlebar templates for us but it can work with almost any front end technology out there. A cool thing is that we can use require within out CoffeeScript files and that allows us to better organize code into modules. Brunch even provides file watching capability so when we save a stylus or CoffeeScript file it will update the browser without a reload. In our setup we compile everything to our django static folder so when we collectstatic, files get uploaded to s3. One thing that was a bit a tricky and something that we have to make better is cache expiration of files. For now we are appending static files with a few characters from the current commit hash (app.css?e2232 something like that), while this is pretty effective we've found some cache systems that ignore it. The next step is to rename files before uploading to s3 (app-e2232.css). I agree that this might be a bit too complicated for most apps but in our case (getblimp.com) we have a pretty heavy JS app and we really need to take advantage of all the "better" front end tools available. I will be willing to contribute to FOSS project to solve this issues once and for all on the django/python side. BTW I think that file watching is better than compiling on every reload during development. In our experience (many js files) request on the development side took seconds and became very frustrating.