{ "info": { "author": "Michael Mulich | WebLion Group, Penn State University", "author_email": "support@weblion.psu.edu", "bugtrack_url": null, "classifiers": [ "Development Status :: 4 - Beta", "Framework :: Buildout", "Intended Audience :: Developers", "License :: OSI Approved :: Zope Public License", "Topic :: Software Development :: Build Tools", "Topic :: Software Development :: Libraries :: Python Modules" ], "description": "================\nIsolation Recipe\n================\n\nThis buildout recipe's sole purpose is to isolate distribution packages and\nthere dependencies. This recipe was originally developed to be used in the\npackaging of Zope2 for the Debian operating system. The recipe can additionally\nbe used to populate a Python enviroment (or virtual environment). This can be\nhandy in situations where buildout is required to build the application, but\nthe developer/system administrator wants to use the application in a typical\nPython environment.\n\nIsolation of distributions\n==========================\n\nThe `buildout.recipe.isolation` recipe can be used to isolate distributions and\ntheir dependencies in a single directory. The recipe takes a number of options:\n\ndists\n A list of distributions to isolate given as one or more setuptools\n requirement strings. Each requirements string should be given on a\n separate line. The default is to use the part name as the distribution.\n\nexclude-dists (optional)\n A list of distributions that should be excluded from the isolation.\n\ndists-location (optional)\n A directory location where the isolated distributions should be put.\n This option\n defaults to a location in the buildout parts directory under the section\n name where the recipe is being used.\n\nscripts-location (optional)\n A directory location where the distribution scripts should be isolated.\n This option defaults to a location in the buildout parts directory under\n the part (or section) name followed by '-scripts' (e.g. for a part\n named *isolated* the default scripts directory name would be\n `isolated-scripts`).\n\n.. _pth_location_opt:\n\npth-location (optional)\n A directory location where a `.pth` file will be created for this isolation.\n This option defaults to a location in the buildout parts directory under\n the part (or section) name followed by '-pth' (e.g. for a part named\n *isolated*, the default pth directory name would be `isolated-pth`).\n\n __ pth_file_location_opt_\n\n The final name of the pth file will be the part name with a `.pth`\n extension. To reference the resulting `.pth` file, use the\n `pth-file-location`__ options.\n\n.. _pth_file_location_opt:\n\npth-file-location (reference only)\n A location where the `.pth` file lives. The resulting `.pth` file is used\n during the script generation process to provide a list of distributions\n that are isolated somewhere else on the filesystem.\n\n .. note:: This option can only be referenced. Later versions of this recipe\n may provide a means to change the pth filename.\n\nextra-pth (optional)\n A list of `.pth` files to include as part of the script initialization.\n\n This option resolves dependency issues caused by dependency isolation.\n For instance, if you are using `exclude-dists` and those distributions\n that are being exluded are required to run a script, you probably want\n to include the `.pth` file with locations to those dependencies.\n\nexclude-own-pth (optional)\n A boolean option, that when set will exclude the in context part's generated\n `.pth` file from inclusion in scripts. This option is closely tied to\n pth-file-location and extra-pth. This option is false by default.\n\n The reason this option has been included is because the locations in the\n `.pth` file main already be included in the python path via the `.pth`\n file's location in site-packages.\n\nexecutable (optional)\n The location of the Python executable. By default this is `sys.executable`.\n \n The executable specified is not executed in the recipe. The location is\n used as the shebang line during the scripts generation.\n\n.. _stage_locally_opt:\n\nstage-locally (optional)\n A boolean option to specify whether we should stage the resources or\n put them in there final destination. If this option is true, the values\n specified for `dist-location`, `script-location` and `pth-location` are\n used to generate the resources, but the resources are placed in\n the default parts locations. This option is handy for staged installation.\n\nRecipe deliverables\n-------------------\n\n- A directory that contains a specified distribution(s) package and its\n dependency package(s).\n- A directory that contains a `.pth` file, which lists the absolute path\n for each package in the isolation context.\n- A directory that contains the scripts that have been generated from the\n distribution(s) package and its dependency packages.\n\nHow it works\n============\n\n\n\nWe have a sample buildout. Let's update it's configuration file to\ninstall the demo package.\n\n >>> write(sample_buildout, 'buildout.cfg',\n ... \"\"\"\n ... [buildout]\n ... parts = demo\n ...\n ... [demo]\n ... recipe = buildout.recipe.isolation\n ... dists = demo<0.3\n ... find-links = %(server)s\n ... index = %(server)s/index\n ... \"\"\" % dict(server=link_server))\n\nIn this example, we limited ourselves to revisions before 0.3. We also\nspecified where to find distributions using the find-links option.\n\nIn order to control the distribution test data, we decided to use buildout's\ntesting index, shown below::\n\n >>> print get(link_server),\n
\n bigdemo-0.1-pyN.N.egg