> Why does this require setuptools, though? I mean, the Python XML > utilities used entry points for extra loaders (e.g. 4Suite) for years > before setuptools came along.
"Before" is the key word there, I think. Now that setuptools is a defacto standard, I think it would be an odd decision to rewrite pieces it. What's the benefit to doing that, when (as someone suggested upthread) you could just bundle setuptools itself, if ez_setup is out? > I'm also a bit confused about your application loading case. What huge > constraints are we putting on app loading at the moment? Apps must be packages which (if they have models) must have models in a file called models.py. You can't even use the ORM without following that convention. Why should that be, except for the loading logic in models.loading? Why can't a class be an app? An instance? Why can't models be anywhere? Tight coupling leads to brittle systems; apps and models are, in my opinion, too tightly coupled to each other and to package layout. Allowing loading of apps through entry points is one way to loosen the ties. > Now clearly this is as > obvious to you as it is to me, so what else are you wanting to do here > that we are currently making hard? What first triggered my thoughts was something seemingly really simple: I was trying to write a test that defined two models related by a many-many relationship. This is currently possible only through hideous hacks, because get_model() only loads models that are in apps, and apps can only be packages and their models can only be in app.models. Defining and installing a model ought to be enough to make it usable. That's not true now, for all models, and the failure cases are very surprising, even when you've been digging around in the model/db code quite a bit. This is easily fixable without setuptools (just let get_models() return all models when called without an app arg instead of iterating the app list and recursing), but it made me think about app loading and packaging and lead to my conclusions above. > Database > backend additions are one that can't be, as you point out. We can fix > that without needing setuptools, it seems. Sure, but why? Setuptools is here, the only detriment to its use is that installing django from source requires either an internet connection or that setuptools is installed already. Why reinvent the wheel? Wouldn't that time be better spent on creating new features? For me this is a classic "build or buy" decision that lands strongly on "buy". JP --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
