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.
