Thanks, Diez. That was really good advice. There were downstream scripts that would have needed changing as well, so I ended up doing something different. But your comment was what pushed me over the top in understanding it.
Basically, I had two problems. The second one was that once one of the TG applications started, it took control of the session and nothing more would run. So I had to make the TG applications run as background processes. What I ended up doing is to use my virtual environments, start the TG application in background, then deactivate the environment, and activate the other virtual environment. Run the second TG application in background. This seems to have worked fine. Thanks so much for your advice. Herb On Nov 4, 10:01 am, "Diez B. Roggisch" <[email protected]> wrote: > On Thursday, November 04, 2010 17:44:10 herb wrote: > > Hi, folks. > > I have been building an appliance in a virtual machine. I have one > > TG2 instance running on one port which is the master dashboard for all > > applications. I have a second instance that I want to run which will > > provide some RESTful functionality on another port. I have two > > virtual environments, one running the dashboard application and > > another application and the second running the new (second TG) > > instance. It all starts up from a script in init.d when the virtual > > machine is started (or at least it is supposed to). > > > Now my real question is this. What is the best way to deploy the two > > TG instances? I can start one virtualenv in the setup script, but I > > get errors if I try to set up a second virtualenv. I still have to > > track down the nature of the errors, but the applications both run if > > I start them by hand in separate terminal sessions. > > > This is what I am doing: > > Activate VirtualEnv1 (source path1_to_bin/activate) > > Start up applications from this virtualenv. > > > Activate VirtualEnv2 (source path2_to_bin/activate) > > start up second TG instance. > > > These are the alternatives I have thought to use: > > (1) deactivate the first VirtualEnv before activating the second > > (could be path issues) > > (2) Move everything around so that there is only one virtualEnv > > (3) Move everything out the virtualEnv. > > > So, any strategic thoughts on how best to proceed? > > You don't need no activation business. Activation is "only" for making your > current shell environment pick the proper commandline tools first. > > Instead, use fully qualified paths to your paster-scripts (and/or python, > easy_install and so forth), and you're good. > > We do that in a two-application mod_wsgi scenario (live/stage) with completely > different VEenvs without a hitch. > > Diez -- You received this message because you are subscribed to the Google Groups "TurboGears" 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?hl=en.
