Package: workingenv.py
Status:the author of workingenv recommends you usevirtualenvinstead of workingenv, as virtualenv
is less likely to bite.ContentsInstallationSummaryChangesActivationRequirementsRegenerating EnvironmentsWindowsZopeUsing workingenv ProgrammaticallyInstallationYou don’t need to install this as a Python package; you can simplydownload the scriptand
run it.  This avoids a chicken-and-egg problem of installing stuff
into your environment so you can start setting up environments.You can also install it witheasy_install workingenv.py, install
it without setuptools (it does not depend on setuptools for
installation), or install from thesubversion repositorywitheasy_installworkingenv.py==dev.SummaryThis tool creates an environment that is isolated from the rest of the
Python installation, eliminating site-packages and any other source of
modules, so that only the modules (and versions) you install into the
environment will be available.  This allows for isolated and
controlled environments, as well as reproduceability.  This is similar
tovirtual-python, but without
the symlinks and with some additional features.The basic usage is:$ python workingenv.py MyNewEnvironment
$ source MyNewEnvironment/bin/activateAfter sourcingbin/activateany commands (likepython setup.py install, etc) will install into the new environment.  A Windowsactivate.batfile is also generated for that environment.  Scripts
likebin/easy_installwill be tied to the environment, and so they
will automatically install into the environment even without
activation.Changes0.6.5: Export$_WE_OLD_WORKING_PATH, etc.  Also deactivate
environments when activating a new environment.  Include the Darwin
Portssite-packagesdirectory on that platform.-envwas
being totally ignored; working now.0.6.4: Use--always-unzipwithez_setup.py, so we don’t
sometimes (on Python 2.5?) get setuptools installed as an egg.  Don’t
put quotes around environmental variables inactivate.bat.  Print
out installation with nesting to show what dependencies are drawn in
by what libraries.0.6.3: Don’t raise an exception whencli|gui.exeis missing.
Setalways_copy = Trueindistutils.cfg, which avoids some
problems with system-wide packages.  Show some indication of progress
during the Setuptools installation.0.6.2: User the system distutils.cfg as well as the
workingenv-specific distutils.cfg; helpful for picking up system-wide
compiler settings.  Fix problem with creating command-line scripts on
Windows (missingcli.exeorgui.exe).0.6.1: Minor bugfix, plus Windows activate.bat file now changes
the prompt (from Patrick O’Brien).  Also, install script as justworkingenvso it doesn’t conflict with the module.0.6: Pulls in dependencies from –requirements files, irregardless of
whether a currently activated environment might provide those
dependencies.  Includes asetup.pyfile.  Doesn’t print out boring
messages fromez_setup.pyandeasy_install.0.5: Fix the self-activation of scripts.0.4: Fix the interaction of the--site-packagesoption (that
brings in the globalsite-packages/directory) and a global
installation of setuptools.  If you get an error like “site.py is not
a setuptools-generated site.py; please remove it” you should upgrade
and regenerate your workingenv.0.3: Support for Setuptools 0.6c5ActivationWhen you “activate” the environment,pythonwill treat that
environment as though it was the only Python environment available.
It does this by setting$PYTHONPATHand overriding the standardsite.py.Installations with “setup.py install” and easy_install will go into
the right place.  Scripts built with easy_install (not other ways)
will be tied to the environment, even if the environment isn’t
activated when the script is run.Activation itself means puttinglib/python2.4/onto$PYTHONPATH.  If you don’t want to usebin/activate, just do:$ export PYTHONPATH=”WORKINGENV/lib/python2.4”
$ <anything using Python>bin/activatealso updates your prompt and sets$PATHto point
to the workingenvbin/.  There is no other magic to it, so you can
reproduce the same functionality that way if you want.  (Note also
thatbin/activatechanges your environment, which is why it must
besourced into a shell environment.)Seethis postfor an
initial discussion.  Discussion should go todistutils-sig@python.org.RequirementsAlso included is the notion of a requirement set, so you can bootstrap
a complete set of packages.  This is a text file witheasy_installable requirements, one on each line.  The file can
also include-rother_fileand-fplace_to_find_packages.
Using this you can provide a very specific working set of packages for
users/developers.  You may also use-ebefore a requirement to
install that requirement intosrc/in development mode.Two examples of this sense of requirements are provided,
“tg-example.txt” and “tg-0.9.txt”.  Note that by putting this into a
separate file, adjusting the requirements in response to testing does
not require changing the requirements of any particular package.  This
way you can give very exacting requirements, and later adjust those
requirements in response to upgrades, without causing instabilities in
any one package.Regenerating EnvironmentsEnvironments carry around the settings they were created with (in.workingenv/).  This allows you to runworkingenv.py ENVIRONMENTover again to make updates, and settings will still be
preserved.Before overwriting any files you will be asked about the changes.
Also you can use--simulateto see what itwoulddo.Windowsworkingenv should work on Windows, but you must useactivate.batbefore starting scripts – they can’t self-activate on Windows.Zopeworkingenv.pywillwork with Zope 2, but you should use the –home
option (which will put everything in lib/python/ instead of
lib/python2.4/).  The way Zope and many Zope Products are set up, they
expect this kind of layout.Using workingenv ProgrammaticallyYou can useworkingenv.main()just like the script; this is
probably the best/safest way to use it programmatically.  Of course
calling it in a subprocess will also work.