So, I've been lurking on this conversation, for a bit, and trying to figure out exactly where to throw my two cents in. Basically, I'm all for having an extension system, and I think that for right now the best way to handle extensions is to use entry points as they are. We *will* have to make changes as we go forward, but I think that's probably inevitable at this point even if we roll our own (we won't get it right immediately!).
As for configuration in the database, I think that can be managed pretty easily if you don't treat the database as a DB so much as a key-value store. If the config is serializable to JSON/YAML, or whatever, you can either store that on disk, or in a DB, with an archived configs table. You could also store it in mongo/couch or in mercurial. If you normalize it and spread it out across a bunch of tables, you'll end up with impossible versioning issues, but that's not really necessary for configuration information anyway. --Mark Ramm On Fri, Aug 13, 2010 at 5:27 PM, Kevin Horn <[email protected]> wrote: > > > On Fri, Aug 13, 2010 at 12:51 PM, Michael Pedersen <[email protected]> > wrote: >> >> So, I've been fretting at one particular problem for a while, and only >> last night came up with a workable solution. This is definitely a question >> to ask the TG community, though. >> >> Some background: I'm working out the ideas for an extension called >> tgext.config. It's going to provide a trac-style web admin interface. It'll >> let extension developers have easy access to configuration variables, and >> keep them stored in the database. The problem has been the database. >> >> I'm a strong believer in the idea that any given component is responsible >> for itself. The problem with this, though, is the question: How do I get the >> extension's database model into the application's database model without >> putting in more steps that the web developer must do? >> >> I think I've come up with a way, though I've not implemented the exact >> mechanics yet. I wanted to get feedback from the community before I do so. >> >> setuptools provides a mechanism called entrypoints. Using this, any given >> Python package can register itself with setuptools as supporting certain >> things. Other packages can then query setuptools to find out which packages >> meet its requirements, and can use those packages. >> >> My thought process is to use this. In the default quickstart, add lines >> which amount to "find all packages that have a tgext.dbmodelext entrypoint, >> and then import the module named by that entrypoint into the current >> myapp/model/__init__.py" >> >> The end result is that extension developers will now be able to seamlessly >> integrate into an application, and the web developer can use any extension >> without worry about properly integrating with the database. >> >> Now, I know that people seem to have hatred of setuptools. So far as I >> know, only setuptools has the entrypoints mechanism. I don't want to write >> yet another plugin mechanism. So, this idea might have issues right from the >> start. >> >> All in all, my major question is this: Why does this idea suck? Without >> any feedback, I'm planning on implementing this idea pretty shortly (within >> the next week). If it is a bad idea, tell me why, so I can try to find a way >> to do this better. >> >> -- >> Michael J. Pedersen >> My IM IDs: Jabber/[email protected], ICQ/103345809, >> AIM/pedermj022171 >> Yahoo/pedermj2002, MSN/[email protected] >> > > I'm very skeptical of any idea which involves storing configuration > information in a database (RDBMS). In my experience this causes more > problems than it solves, especially as applications grow in size and > complexity. The biggest problem with this approach (in my opinion, at > least) is that once you start storing config info in a database, it becomes > _very_ difficult to version-control. In my experience this ends up causing > all kinds of nasty administrative problems down the road. Of course, that > begs the question, what to do instead? > > I don't have a great answer to that question, but here's a few ideas: > 1) At the very least, allow this configuration info to be stored in a > separate database, away from your main application database. This at least > allows the administrator to set things up so that they can more easily > migrate config data between server/app instances/whatever. > 2) Write your web interface to store config data in text files, just as is > done now. You can use either the stdlib ConfigParser or ConfigObj for > this...ConfigParser should do a much better job starting with Python 2.7 > than in previous versions, due to the fact that it uses OrderedDicts now. > This approach has it's own issues, like handling automated edits vs. manual > edits, but those problems exist in just about any config-data-managing > scheme (including using DBs). > 3) If you want to get really crazy, create a nice generic interface for > loading/storing the config data, and allow for a number of different backend > sources for this data. Of course, tehn you might need config data to tell > you where your config data is... :) > > The only reason I would be against using setuptools (via entrypoints) is > that it _will_ be going away...eventually. However, this will likely take > quite a while, and the distribute package should provide a fallback in case > of future problems with the "official" setuptools release. So I think using > setuptools' entrypoints is probably fine for now, with the following > caveats: > > 1) there are a number of people who will not use any application that relies > on setuptools, so be prepared to listen to some people gripe > 2) be prepared for some pain when/if you ever need to change to whatever the > replacement for entrypoints ends up being > > Good luck! > > Kevin Horn > > -- > You received this message because you are subscribed to the Google Groups > "TurboGears Trunk" 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/turbogears-trunk?hl=en. > -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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/turbogears-trunk?hl=en.
