Jorge Vargas wrote:
> On 1/25/07, Alberto Valverde <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> I was planning to write something soon to share what my thoughts have
>> been recently regarding TG's future but been very busy with paid work
>> (and will be until late february). Anyway, here is an update to bring
>> up some discussion and maybe clear some uncertainties.
>>
>> After thinking about it, meditating the past thread regarding this
>> same issue, reading some blogs/wikis and experimenting, I think TG
>> 1.1 (yep, 1.1) could start migrating to CherryPy 3 and a PasteDeploy
>> style configuration file for deployment.
> that will be good CP will bring a lot of speed, as for paste it's
> great since the current deploy system is very complex, specially went
> people forget to move their *.cfg files. can we explore the
> possibility of having only one config file? most of dev/prod is just
> duplicated from one to the other. I was thinking of having a common
> section which will be the ones being [foo] and then have subsections
> like [foo.dev] and [foo.prod].
Well, in Paste generally I just have two config files. But you can do
something like:
[app:generic]
use = egg:MyApp
setting1 = foo
setting2 = bar
[app:dev]
use = generic
setting1 = foo-dev
debug = true
[app:main]
use = generic
debug = false
Then you can serve up from the main or dev section (main being the
default). Or you can have them pick up values from other files (e.g.,
use = config:generic.ini), or whatever. I abhor boiler plate in config
files, and once the boiler plate is gone having two config files isn't
so bad.
>> What I mean by "possible" is that a single TG app doesn't really need
>> a paste.deploy config file and the CP configfile, built by the
>> developer, we're used to is enough. A paste.deploy config is needed
>> when a TG app distributed as an egg wants to be mounted side by side
>> in a bigger site.
> that sounds like too many config files, I believe we need to think
> this better, they are all dict based files. I see 3 possible solutions
> a) handle then totally separated backed by docs, howto write a
> paste.deploy config file, howto .... b) Do some python-foo to build
> the config files automagically, c) have one BIG config file with all
> the options and do less python-foo to build the separated ones.
If you want to build up the config in Python or some custom way, you'd
just want to conform to the paste.* entry points (app_factory,
filter_factory, etc).
You could also just use the Paste way of accessing things from
everywhere. Paste doesn't allow a single application to have
subsections, but the keys can look like whatever you want, so if you
really want "/foo session_timeout = 60" or something, you could parse
that into {'/': {'session_timeout': '60'}}. I dunno... generally I find
this kind of control unnecessary once you've split things into formal
apps -- overriding things by path inside an application is error prone.
Also I think there's a config file inside TG projects, right? While you
can do that, I prefer just putting that into Python code. So that means
any stuff that isn't optional or shouldn't be configured on deployment
goes into Python code. I haven't kept up with TG on this, but I seem to
remember it was putting some of that stuff into config files inside the
package.
>> - We can start investigating/stealing useful tools from other
>> projects.... (I18NToolbox, Pylons version of EvalException,
>> HTTPEncode, etc, etc...)
BTW, I've thought about splitting off the Paste exception stuff into a
separate project, and doing some potentially backward-incompatible
changes to support better templating and customization, leaving the
Paste stuff stable (which is why the Pylons changes haven't made it back
into Paste) and only deprecating the Paste stuff when the new project is
stabilized.
(HTTPEncode, OTOH, shouldn't be used outside of experiments yet because
I'm still heavily refactoring it.)
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
