4 ms·

Django packages are often awwwwwfully tempting but the more of them you use the more likely things are to start acting weird (they don't all play nicely togethe

by ris 9y ago

Django packages are often awwwwwfully tempting but the more of them you use the more likely things are to start acting weird (they don't all play nicely together) and the more pain you're going to have upgrading Django versions. IRS really important to assess whether you really need all the complexity any add-on brings. This also leafs me to favour more stay-out-of-my-way add one like django-silk over django-debug-toolbar

spapas82 9y ago
I have a different philosophy. If some functionality is offered by a good-quality (supported, good docs etc) django package then go on and use it. If you want to be DRY you shouldn't re-implement functionality that others have already implemented. Also, after you use a package you more or less learn it and it's easy to re-use it in your next project -- while if you implement your own solution you'll most probably need to resort to horrendous copy and paste from your old project to your new one to re-use it! Also, as I already mention in my article, if you use a package and you use it for its intented purpose you have a quick reference for some of your project's functionality (f.e if you use django-waffle then you'll know that some parts of the project can be enabled or disabled at will) - if instead you had implemented everything yourself you (or the person that needs to understand your project) would need to read everything to know what's happening. So, for me, using a good django package does not add but actually removes complexity from your project! I can't remember any package incompatibilities - instead as I already mention in my article there are a lot of packages that work great together (django-tables with django-filter, django-rest-framework with django-filter, django-taggit with django-autocomplete-light etc). Finally, I partially agree with your comment about more pain when upgrading django versions however considering that - supported projects are usually upgraded a little after a new version of django is out (most of them are already prepared before the new django version is out since they can be tested using the beta version) - django keeps supporting (non LTS) old versions for 8 months (and 16 months for securiy fixes) so in this time most probably all your dependecies will have updated so as to support the new django version - all packages are open source so you can contribute to help move to the next version the upgrading pain should be very little... When I upgraded from django 1.10 to 1.11 I also upgraded all the packages I describe in the list and everything worked without problems!

by ris 9y ago

spapas82 9y ago

I have a different philosophy. If some functionality is offered by a good-quality (supported, good docs etc) django package then go on and use it. If you want to be DRY you shouldn't re-implement functionality that others have already implemented. Also, after you use a package you more or less learn it and it's easy to re-use it in your next project -- while if you implement your own solution you'll most probably need to resort to horrendous copy and paste from your old project to your new one to re-use it! Also, as I already mention in my article, if you use a package and you use it for its intented purpose you have a quick reference for some of your project's functionality (f.e if you use django-waffle then you'll know that some parts of the project can be enabled or disabled at will) - if instead you had implemented everything yourself you (or the person that needs to understand your project) would need to read everything to know what's happening. So, for me, using a good django package does not add but actually removes complexity from your project! I can't remember any package incompatibilities - instead as I already mention in my article there are a lot of packages that work great together (django-tables with django-filter, django-rest-framework with django-filter, django-taggit with django-autocomplete-light etc). Finally, I partially agree with your comment about more pain when upgrading django versions however considering that - supported projects are usually upgraded a little after a new version of django is out (most of them are already prepared before the new django version is out since they can be tested using the beta version) - django keeps supporting (non LTS) old versions for 8 months (and 16 months for securiy fixes) so in this time most probably all your dependecies will have updated so as to support the new django version - all packages are open source so you can contribute to help move to the next version the upgrading pain should be very little... When I upgraded from django 1.10 to 1.11 I also upgraded all the packages I describe in the list and everything worked without problems!