On 8/16/07, Cliff Wells <[EMAIL PROTECTED]> wrote: > On Wed, 2007-08-15 at 19:15 +0200, Neil Blakey-Milner wrote: > > > Or, even better, use virtual-python or workingenv, and never install > > moving targets into your core Python library location. > > Out of curiosity, what does workingenv offer over the standard > setuptools way of doing things? > > http://peak.telecommunity.com/DevCenter/EasyInstall#administrator-installation
I use virtual-python, but workingenv works similarly enough, so I'll just answer as per virtual-python. Basically, I maintain a project directory per separate application that runs on a server. At work, I have projectA (a Django server), projectB (a port of that application to TurboGears), and projectC (a new TurboGears project). In development, each one has a totally separate virtual-python environment. This environment is periodically cleared and restarted. The data in setup.py's "install_requires" is used to install all the packages that are necessary (using dependency_links to use a common local storage location for both third-party and our own packages) for that, so we can be sure that when we go live, we'll have all the packages and versions of them necessary to run. On live, we actually have two totally separate virtual-python environments. Basically, it's the current live running environment, and the previous live environment. When we install a new (major) version, we create a new environment and install the egg package produced by our project, which then fetches all its dependencies. We then shut down the running live environment, back up the database, run the database upgrade scripts, and start up the new live environment. We then run tests, and if all goes well, we move forward with this environment. If things don't work well, we restore the database, and start up the previous live environment. Using workingenv or virtual-python means being able to create these in any location, with any user, and generally be flexible about it. workingenv also has some additional useful functionality - but I just found virtual-python first, and the additional functionality in workingenv is dealt with in my egg package installs anyway. Also, generally our live environments are installed with one user, and run with another user (who can't change the code/resources). The "user installation" wouldn't work in this scenario. Neil -- Neil Blakey-Milner http://nxsy.org/ [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
