I tend to believe the opposite is true. Django was/is a successor in its
field, because it offers an "out-of-the-box" or "batteries included"
experience. Subsequently parts were shaped as needed for that bigger
picture, e.g. the ORM became what it is today.
Does anyone still remember django versions with external south
migrations? Was much more tricky to get done right, ppl would just
forget it, do it in wrong order, whatsoever. Got basically fixed by the
tighter integration with typical django project lifecycling.
By making the ORM an external lib with its own progression and
versioning you'd reintroduce all that fuzz again, plus frictions from
API changes, that seem logical from a db maintainer viewpoint, but make
life harder at consumer end (would be django here). By keeping it in one
place those tiny viewpoint differences can be leveled out upfront.
Ofc mammoths move slower, but they are also more resilient against
disturbance. In terms of good long term maintainability the more
granular/agile approach as seen in the JS-world still has to prove
itself. Projects there need a lot more care&love of their dependency
lists, and typically wont run anymore after 1-2 years without manually
fixing this or that, because package xy of 100+ dependencies turned its
API upside-down for no good reason.
So no, outsourcing things is not always a good idea.
All imho, ofc.
Cheers,
Jörg
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/aaf069ac-8db2-f538-6fe9-95d49bf49bc9%40netzkolchose.de.
