5 ms·

Excellent. Pile up your django with extensions, then look forward to the fun when you have to port your app from e.g. django 1.3 to 1.5 and find a new set of ve

by ris 13y ago

Excellent. Pile up your django with extensions, then look forward to the fun when you have to port your app from e.g. django 1.3 to 1.5 and find a new set of versions of all of your dependencies that work nicely together. And of course figure out a migration path for it all. That is, if extension xyz is still maintained at all. Lean is beautiful, people. Carefully assess every dependency you add, as each one has the potential to become a burden.

dmishe 13y ago
Yep
StavrosK 13y ago
Wait. If you need a piece of functionality, you either get something that works out of the box, or you spend X hours writing it. If the out-of-the-box thing breaks and you spend Y hours fixing it, then Y has to be much greater than X to not be worth it, which, in my experience, it never is. Not to mention that, if the library broke, then the thing you would have written would have probably broken as well, and you wouldn't have the benefit of a thousand other users who might have had (and fixed) the problem before you. This just smells of FUD to me, as it rarely is a problem to me in practice.
- joshlegs 13y ago
  really have to agree with you. why would you ever spend time writing some functionality that someone else already has, unless what's out there is just total shite.
- ris 13y ago
  > If you need a piece of functionality Depends what you mean by "need". Often when you need a piece of functionality, what you actually "need" is a small subset of what a third party app is wanting to provide, and I've often found simply using out-of-the-box apps for this adds a fairly huge amount of complexity that is just not needed. My favourite case in point would be adding very simple blog functionality to something - which is fairly quick & trivial in django, but out-of-the-box blog solutions promote themselves with tempting-features-that-you-dont-really-need that inadvertently add a lot of complexity and before you know it you're a few releases down the line and you realize that the author doesn't really know how to use South properly and your db ends up in a slight migration-state-limbo forevermore. Though note that I am _not_ saying don't use external dependencies - I use several of those listed in the article (I am a big fan of django-reversion) - but remember to look at everything with a critical eye before inclusion. > This just smells of FUD to me It's all very well and good saying that but a stack of previous bad experiences doesn't smell like FUD when you're on this end of them.
  - StavrosK 13y ago
    Ah, you're right there, if you're talking about a blog app, I agree with you. I had much smaller pieces in mind, such as the packages I mentioned before. Each one of those does one specific thing and does it well. Blogging is pretty much the worst example here because it's highly, highly custom to each person and easy enough to write that you wouldn't bother with a library, which would end up not doing what you want in the long run anyway. Something like shortuuid, on the other hand, is pretty much a slot-in.
deleted 13y ago
[deleted]
andybak 13y ago
I've had to handle this multiple times as my Codebase was started on Django 0.96 and currently supports Django 1.6 3rd party libraries upgraded painlessly in 90% of cases aside from those few that had been abandoned. And usually they were abandoned because the community had coalesced around a much better library. So 3rd party code? Change a line in requirements.txt and bam. My own code? Had to upgrade it manually each time.
- ris 13y ago
  > Change a line in requirements.txt and bam. 90% of the time as you say so yourself.

by ris 13y ago

dmishe 13y ago

Yep

StavrosK 13y ago

Wait. If you need a piece of functionality, you either get something that works out of the box, or you spend X hours writing it. If the out-of-the-box thing breaks and you spend Y hours fixing it, then Y has to be much greater than X to not be worth it, which, in my experience, it never is. Not to mention that, if the library broke, then the thing you would have written would have probably broken as well, and you wouldn't have the benefit of a thousand other users who might have had (and fixed) the problem before you. This just smells of FUD to me, as it rarely is a problem to me in practice.

joshlegs 13y ago
really have to agree with you. why would you ever spend time writing some functionality that someone else already has, unless what's out there is just total shite.
ris 13y ago
> If you need a piece of functionality Depends what you mean by "need". Often when you need a piece of functionality, what you actually "need" is a small subset of what a third party app is wanting to provide, and I've often found simply using out-of-the-box apps for this adds a fairly huge amount of complexity that is just not needed. My favourite case in point would be adding very simple blog functionality to something - which is fairly quick & trivial in django, but out-of-the-box blog solutions promote themselves with tempting-features-that-you-dont-really-need that inadvertently add a lot of complexity and before you know it you're a few releases down the line and you realize that the author doesn't really know how to use South properly and your db ends up in a slight migration-state-limbo forevermore. Though note that I am _not_ saying don't use external dependencies - I use several of those listed in the article (I am a big fan of django-reversion) - but remember to look at everything with a critical eye before inclusion. > This just smells of FUD to me It's all very well and good saying that but a stack of previous bad experiences doesn't smell like FUD when you're on this end of them.
- StavrosK 13y ago
  Ah, you're right there, if you're talking about a blog app, I agree with you. I had much smaller pieces in mind, such as the packages I mentioned before. Each one of those does one specific thing and does it well. Blogging is pretty much the worst example here because it's highly, highly custom to each person and easy enough to write that you wouldn't bother with a library, which would end up not doing what you want in the long run anyway. Something like shortuuid, on the other hand, is pretty much a slot-in.

deleted 13y ago

[deleted]

andybak 13y ago

I've had to handle this multiple times as my Codebase was started on Django 0.96 and currently supports Django 1.6 3rd party libraries upgraded painlessly in 90% of cases aside from those few that had been abandoned. And usually they were abandoned because the community had coalesced around a much better library. So 3rd party code? Change a line in requirements.txt and bam. My own code? Had to upgrade it manually each time.

ris 13y ago
> Change a line in requirements.txt and bam. 90% of the time as you say so yourself.