Hey Bill, OK, maybe it's just because it's early in the morning or because I'm a bit stupid, but I'm not sure that I am understanding what you are suggesting in some cases here. A few requests for clarification below...
On Wed, 2006-08-02 at 21:39 +0100, Bill de hÓra wrote: > 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. Are you in agreement or disagreement with checking for dependencies via __init__.py? I wasn't suggesting we don't also install them in INSTALLED_APPS -- I was just trying to show there were ways of checking dependencies using existing Python infrastructure. Thinking about my suggestion a bit more, though, after I wrote it, I thought it might be useful to have a helper function that at least checked the required app was in INSTALLED_APPS already (not just Python importable). Is that what you are getting at as well? > > > > 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. So, I wrote a poorly constructed sentence, with lots of negatives in it. And you agree with a smiley. Oh (30 seconds later)... you're suggesting the "do nothing" approach is easier: easy for developer, hard for site maintainer? OK, I probably need to get a humour gland replacement. > > 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. Agreed. This was something I was having to explain in my chat with the Drupal guy as well. That Django was a little more generic than Drupal. > > 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. At the end of the day, this stuff is really hard. I think we can try to get to a point where the easy hurdles are maybe handled automatically and the more subtle stuff requires the installer to actually read the README that comes with an application. There will still be problems because of slight API incompatibilities. It's analogous to trying to maintain perfect API/ABI compatibility in C libraries across version upgrades, and that stuff's serious rocket science. Either we formally describe all the APIs that are exposed from an app (yuck!) or we have a few bumpy patches in the installation path (a little more palatable in rapid development/deployment situations, I feel). Maybe we need to encourage putting a __version__ string or somesuch in an app's __init__.py to enable compatibility checking (combined with searching for the app in INSTALLED_APPS at validate- and run-time). Then we educate people in what it means to bump the minor version number (compatibility maintained) version the major number. There are lots of examples to draw on from other projects. Getting some concrete ideas to try out is probably worth it. Do you have any concrete ideas here, Bill? Other than "everything has drawbacks"? :-) Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
