On Wed, 2006-08-02 at 17:23 +0000, [EMAIL PROTECTED] wrote: > > So, convince us to continue using setuptools. What incentive do we > > have to keep using it? I'm not sure the convenience of easily being > > able to specify a manifest outweighs the horrid stain of requiring an > > Internet connection just to install our software. Are there any other > > ways we can take advantage of it, perhaps? > > Here are a couple that I've been thinking about, both using setuptools > entry points. > > Easy: make database backends pluggable. There's no good reason for all > db backends in the world to go in core, nor for users to be unable to > use custom backends without hacking core. This could be solved with a > tiny change in django.db: if the backend isn't in core, look under the > 'django.db.backends' entry point and load whatever you find there under > the requested name. > > Harder: make app loading use entry points. models.loading is ... not > the least hacky part of django. :) The app/model structure constraints > are quite difficult to work around. Entry points could make app loading > much easier and more flexible. Just iterate the django.applications > entry point and call everything you find there an app. No more need to > dictate package layouts ... plus with apps distributed as eggs, you > have a solution to the absolute/relative package loading problems > caused by the practice of copying apps from one project to another. > > In summary: entry points *rule*. My experience with using them to add > plugin support to my test runner (nose) left me with a great respect > for their power to make a framework much more open and hacker-friendly, > at minimal cost. Dependency loading and versioning and such are great, > but to me entry points are *the* reason to use setuptools.
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. I'm also a bit confused about your application loading case. What huge constraints are we putting on app loading at the moment? Relative imports work -- in the sense that you don't need project name in the import path -- so copying apps between projects should be reasonably simple. I would have thought that most of the time somebody is using an application with Django, there is no need to hack the source at all. The app has to be on the Python path and importable. 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? Whenever I'm evaluating additions to the code, one of my questions is always "can this be done outside of the source?" Usually the answer is yes (template loaders, apps, template tags, filters, ...). Database backend additions are one that can't be, as you point out. We can fix that without needing setuptools, it seems. 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 -~----------~----~----~----~------~----~------~--~---
