On Thu, 2006-08-03 at 01:02 +0000, [EMAIL PROTECTED] wrote: > > 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?
See, this is where I think you are wanting to do more than just using extra loading hooks. There's no big rewrite involved. Have a think back to how XML stuff was imported in, say, Python 1.5: it was like one line of code to do the extra search (inside Python core libraries, not something the user had to worry about). > > 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. This is wandering very far from "should we use setuptools". You are talking about a large redesign of the model system towards infinite flexibility. That's probably a topic for another thread. It's not really tied to setuptools usage beyond you think it would make it easier to leverage those changes in the future if setuptools were available (or am I misunderstanding?). [... snip...] > > 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". Maybe I'm not being clear: how is setuptools even involved in the case of looking for extra database backends? Either they are available underneath a search from some module path (which could be a standard location of a configuration option so that we can have backends out of tree) or they aren't. What does setuptools add to the picture? (Serious question. I think I must be missing something fundamental, since I have plenty of hooks in applications I've written that don't use setuptools, so I'm wondering what else it's bringing along.) Cheers, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
