Malcolm Tredinnick wrote: > Hi Todd, > > On Sat, 2006-07-29 at 19:42 -0400, Todd O'Bryan wrote: >> 3. Develop some kind of explicit way that apps can declare >> dependencies on other apps so that apps can just be dropped in with >> any dependencies, their prefixes set, and they be good to go. > > I think this is possibly best solved by just importing the other > applications in __init__.py. That way, "manage.py validate" and any use > of the application will fail at the very first import. So if my weblog > app depends on my tag app, putting "import tagging" in > weblog/__init__.py enforces the dependency.
That would be leave mechanisms; python __init__.py and INSTALLED_APPS. INSTALLED_APPS works for me. I don't see the problem in forcing apps to explicitly register centrally. It's preferable to implicit bilateral dependencies which will become unmaintainable in short order. Ok, you have an __init__.py, but INSTALLED_APPS at least obliges app developers to think about the deploy/runtime context. > Just my personal feeling, but I think using Python's built-in dependency > enforcement like this is preferable to adding any extra infrastructure > to Django. I can't imagine we could do anything that would be much more > simple than "import foo" without imposing a burden on the app developer. I can :) It'll tend be a burden on whomever manages the site. > I was having a conversation at OSCON yesterday with a Drupal developer > and discussing how Drupal handles things like dependencies and > "installation profiles" (as they call them) and I mentioned to him that > we probably don't have the experience yet in Django to really know what > are "best practices" for the framework. Plone (products) and Eclipse (osgi) do a good job structurally. But any kind of plugin framework models suggest Django shift from being a web framework to an app server. It's quite a difference, imo. > We have some good ideas and there is some consistency already and the > benefit of the substantial experiences of a bunch of guys from Kansas, > but are there better ideas available? What problems are people seeing in > other circumstances Are we converging on a "local" best, rather than > *the* best? Hearing different ideas -- particularly those backed up by > real-world deployment experience can only help, even if they only > provide anti-use-cases. Real world cases suggest plugin frameworks are the way to go, combined with an understanding what the runtime dependencies really are between apps. Especially dealing with the following issues - 1) where the two apps you want require conflicting libraries (that's dll/jar hell); 2) where you can't upgrade django core/contribs, because one of your apps will break (that's plone/eclipse hell). These are very real, very nasty problems that come with component/plugin models. cheers Bill --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
