{
"info": {
"author": "Roger Ineichen, Projekt01 GmbH",
"author_email": "dev@projekt01.ch",
"bugtrack_url": null,
"classifiers": [
"Development Status :: 4 - Beta",
"Environment :: Web Environment",
"Framework :: Zope3",
"Intended Audience :: Developers",
"License :: OSI Approved :: Zope Public License",
"Natural Language :: English",
"Operating System :: OS Independent",
"Programming Language :: Python",
"Topic :: Internet :: WWW/HTTP"
],
"description": "This package provides a product build, release and deploy system based on\npackage versions using zc.buildout. The core concept is taken from keas.build\nand provides the same configuration syntax. The main difference is that we\ndon't setup the install script as ``install`` because there is a conflict with\nthe gnu install script call on ubuntu (pycairo, python waf install) used by a popen recipe (p01.recipe.setup:popen). This implementation will offer the\ninstall script as a ``deploy`` entry_point. The deploy entry point called deploy\nwas removed and is not supported. Use salt or another concept for calling the deploy method your your server.\n\n\n======\nREADME\n======\n\n``p01.build`` is a command line tool for quickly creating new (egg) releases.\n\n\nSample\n------\n\nAs an example, consider a web application called MyServer:\n\n- ``p01.cdn`` - cdn resources like css and javascript files\n\n- ``p01.core`` - a package providing your application model\n\n- ``p01.web`` - a web front end for the ``p01.core`` package and using the\n p01.cdn resources\n\nUsing ``p01.build`` you will be able to manage the lifecycle of these\npython packages and any number of deployment configurations coherently:\n\n- Allow you to define a project, which is a collection of\n interdependent eggs that generally get released together.\n\n- Automatically deploy new egg releases of each package when necessary.\n\n- Upload new eggs to a private egg repository (see mpypi).\n\n- Generate versioned buildout configuration files that combine the\n eggs properly.\n\n- Upload the buildout configuration files to a private configuration server.\n (mypypi has built in support such uploads)\n\n- Upload dependent buildout configuration files to a private configuration\n server (by checking the extends= chain, mypypi support such uploads)\n\n\nInstallation\n------------\n\nInstall the ``deploy`` script with easy_install::\n\n $ easy_install p01.build\n\nYou can also install a developer version of p01.build\n\nCheckout the code::\n\n $ svn checkout svn://svn.zope.org/repos/main/p01.build/trunk p01.build\n $ cd p01.build\n\nRun the bootstrap script and buildout::\n\n $ python bootstrap.py\n $ ./bin/buildout\n\n\nRelease\n-------\n\nOnce you have working developer version available, you should be able to run\nthe ``build-package`` script. (Found in *./bin/build-package* with developer\ninstallations)::\n\n $ build-package\n Usage: build-package [options]\n\n Options:\n -h, --help show this help message and exit\n -c FILE, --config-file=FILE\n The file containing the configuration of the project.\n -q, --quiet When specified, no messages are displayed.\n -v, --verbose When specified, debug information is created.\n -d, --use-defaults When specified, no user input is required and the defaults are used.\n -o, --offline-mode When set, no server commands are executed.\n -n, --next-version When set, the system guesses the next version to\n generate.\n -b BRANCH, --use-branch=BRANCH\n When specified, this branch will be always used.\n -i BRANCHES --independent-branches=BRANCH1 BRANCH2,\n When specified, the system guesses the next version from all this branches. This is important to set if\n you release from different branches. It will prevent\n that a package get used which was released from\n another branch !!!\n --no-upload When set, the generated configuration files are not\n uploaded.\n --no-branch-update When set, the branch is not updated with a new version\n after a release is created.\n -s PATH, --storage-path=PATH\n Store the generated files in that folder and not in\n the global root directory. This is just for provide\n a clean setup and prevent to put all the generated config files\n\n\nGetting Started\n---------------\n\nAssumptions; First we need to start with some assumptions that p01.build has\nabout the way packages are laid out. When developing multiple packages in\ntandem, it often makes sense to have your subversion repository laid\nout like so::\n\n SVNROOT/MyServer/packages/\n branches/\n Branch-0.x/\n ...\n Branch-1.x/\n p01.cdn/\n p01.core/\n p01.web/\n tags/\n p01.cdn-0.5.0/\n p01.core-0.5.0/\n p01.core-0.5.1/\n p01.web-0.5.0/\n p01.web-0.5.1/\n p01.web-0.5.2/\n ...\n trunk/\n p01.cdn/\n p01.core/\n p01.web/\n\nThe important thing to note is that each package does *not* have its\nown branches/ tags/ trunk/ directories, but rather there is just one\nset of the entire \"project.\"\n\n\nProject setup\n-------------\n\nBefore you can really do anything with the ``build-package`` script,\nyou have to define a configuration file. Project configuration files\nuse the INI [#ini]_ file format. Every project configuration file\nmust have a ``[build]`` section. The project configuration file for\nthe MyServer would look something like this::\n\n\n # MyServer.cfg\n\n [build]\n name = MyServer # this has nothing to do with the package namespace\n version = +\n template = release.cfg\n tag-layout = subfolder\n upload-type = setup.py\n package-index = https://pypi.projekt01.ch/private\n package-index-username = username\n package-index-password = password\n buildout-server = https://pypi.projekt01.ch/++projects++/\n buildout-server-username = username\n buildout-server-password = password\n svn-repos = https://svn.projekt01.ch/svn/myserver/packages/\n svn-repos-username = somesvnuser\n svn-repos-password = somepass\n svn-trust-server-cert = 1\n packages = p01.cdn\n p01.core\n p01.web\n\nLet's go over each of the settings in the ``build`` section of\n*MyServer.cfg*.\n\n- **name** - This is the name of the project. It can be anything you\n want and has nothing to do with the packages that make up the\n project. The name will be part of the generation buildout\n configuration files.\n\n- **version** - This is the version to use when making a new release\n of the Project. The version number becomes part of the filename for\n the generated buildout configuration files.\n\n - Using **+** as the version will simply increment the version\n number of the project from the versions that have already been\n released.\n\n- **template** - This is a base buildout configuration file to use for\n all deployments. When a new Project release is created, the\n ``[versions]`` section will automatically be updated with the\n correct versions of each of the ``p01.*`` packages. More on\n this later.\n\n- **tag-layout** - Choose from ``flat`` or ``subfolder``\n\n - **flat** Tags will be created in svn as /tags/package-version\n This is the default setting.\n\n - **subfolder** Tags will be created in svn as /tags/package/version\n\n- **upload-type** - Choose from ``internal`` or ``setup.py``\n\n - **internal** Upload packages to a WebDAV enabled web server using the\n below credetials. This is the default setting.\n (actually does a ``python setup.py sdist`` and uploads the result)\n\n - **setup.py** Executes ``python setup.py sdist register upload``,\n does nothing else as this command should take care of the upload.\n\n- **upload-format** - setup.py release format option use as --formats argument.\n Choose from ``zip``, ``gztar``, ``bztar``, ``ztar`` or ``tar``. Note, there\n is only one format option allowed.\n\n- **package-index** - The url to a WebDAV [#webdav]_ enabled web\n server where generated eggs for each of the ``p01.*`` packages\n should be uploaded. Used for upload only if ``upload-type`` is ``internal``.\n Also used to check/get existing versions of packages.\n\n- **package-index-username** - The username for accessing the WebDAV\n server\n\n- **package-index-password** - The password for accessing the WebDAV\n server\n\n- **buildout-upload-type** - Choose from ``webdav``, ``local`` or ``mypypi``\n\n - **webdav** Upload generated buildout files to the url specified by\n ``buildout-server`` with the WebDAV protocol.\n\n - **local** Just generate buildout files, don't upload them.\n If ``buildout-server`` is given buildout files will be copied to that\n folder.\n\n - **mypypi** Upload generated buildout files to the url specified by\n ``buildout-server``. The url should point to the mypypi upload page.\n (Something like http://yourhost/++projects++/)\n\n- **buildout-server** - The url to a WebDAV enabled web\n server where generated buildout files should be uploaded.\n If ``buildout-upload-type`` is ``local`` this is a path on the local\n filesystem. Buildout files wil be copied to this folder.\n If not given, the process stops after releasing the packages.\n\n- **buildout-server-username** - The username for accessing the WebDAV\n server\n\n- **buildout-server-password** - The password for accessing the WebDAV\n server\n\n- **svn-repos** - The url for the subversion repository where all the\n source code lives, including release tags.\n\n- **svn-repos-username** - The username for the url repository.\n Use the command line option ``--force-svnauth`` to force all svn operations\n to use this credential.\n Otherwise cached authentication will be used.\n\n- **svn-repos-password** - The password for the url repository.\n\n- **svn-trust-server-cert\"\" - Trust svn server certificate.\n\n- **hash-config-files** - Add hashes based on file content to dependent config\n filenames.\n\n- **packages** - a list of packages that are part of the project.\n These are the packages that live in the svn repository and that\n should be released in conjunction with each other.\n\n\nDefining a Release Template\n---------------------------\n\nAs we saw in the previous section, *MyServer.cfg* refers to a file\ncalled *release.cfg*. This is just a base buildout configuration. Additional\nto this, we can also define different configuration data as define in stage and\nproduction section. Such sections can get used in a product deployment as\nadditional (shared) variables. For the MyServer project, it might look like\nthis::\n\n # release.cfg\n\n [buildout]\n extends = http://download.zope.org/zope3.4/3.4.0/versions.cfg\n parts = test\n find-links = https://pypi.projekt01.ch/private\n\n [test]\n recipe = zc.recipe.testrunner\n eggs = p01.cdn\n p01.core\n p01.web\n\n [app]\n recipe = zc.zope3recipes:app\n servers = zserver\n site.zcml = \n eggs = p01.web\n\n [zope3]\n location =\n\n [stage]\n memcached = 127.0.0.1:11211\n\n [production]\n memcached = 10.0.0.1:11211\n\n\nWhen a new release of the MyServer project is made, a ``[versions]``\nsection will be added to this configuration file with all the\ncorrect ``p01.*`` versions pinned down.\n\n\nDefining Multiple Deployment Configurations\n-------------------------------------------\n\nEach time you release a Project, you may want to generate different\nbuildout configuration files for all the different deployment\nenvironments you might have. For example, you may have three\ndifferent environments: Development, Stage, and Production. These are\ncalled variants. Each environment may need to have the application\nrun on different ports, at different log levels, or have other small\ndifferences.\n\nWe can easily generate additional configuration variants by adding\naddtional sections to the *MyServer.cfg* file::\n\n # MyServer.cfg\n\n [Development]\n template = instance.cfg\n vars = stage\n port = 9080\n logdir = /opt/myserver/dev/logs\n install-dir = /opt/myserver/dev\n loglevel = debug\n cache-size = 1000\n\n [Stage]\n template = instance.cfg\n vars = stage\n port = 9082\n logdir = /opt/myserver/stage/logs\n install-dir = /opt/myserver/stage\n loglevel = info\n cache-size = 1000\n\n [Production]\n template = instance.cfg\n vars = production\n port = 8080\n logdir = /var/log/myserver\n install-dir = /opt/myserver/\n loglevel = warn\n cache-size = 200000\n\nWe can then have a single *instance.cfg* file that uses python's built in\nstring templating to access the variables we set in *MyServer.cfg*. For the\nMyServer project, it might look like this::\n\n # instance.cfg\n\n [buildout]\n parts += server\n directory = %(install-dir)s\n\n [database]\n recipe = zc.recipe.filestorage\n\n [server]\n recipe = zc.zope3recipes:instance\n application = server-app\n zope.conf =\n\n \n memcached %(memcached)s\n \n\n \n cache-size %(cache-size)s\n \n path ${database:path}\n \n \n\n \n type WSGI-HTTP\n address %(port)s\n \n\n \n level %(loglevel)s\n \n formatter zope.exceptions.log.Formatter\n path %(logdir)s/server.log\n \n \n\n \n \n level info\n path %(logdir)s/server-access.log\n \n \n\nAs you can see, the MyServer.cfg uses additional vars (stage, production) which\nmakes it very simple to define a lagrge amount of shared attributes in a\nrelease template and use them in the instance template. Note, a side effect\nfrom the python config parser is, that you will inherit arguments define in a\nduplicated section define in an template loaded via (buildout) extends.\n\n\nReleasing a Project\n-------------------\n\nOnce you have created all the necessary configuration files, you can\nmake your first project release. This is where the ``build-package``\nscript comes in to play. The first time you run the ``build-package``\nscript, the only option you need to pass in will be the configuration\nfile.\n\nThe ``build-package`` script will prompt you for version information\nabout each of the packages it will be releasing as part of the\nMyServer.cfg project. Your first interaction with the script might look\nlike this::\n\n $ build-package -c MyServer.cfg --quiet\n Version for `p01.cdn` : 1.0.0\n The release p01.cdn-1.0.0 does not exist.\n Do you want to create it? yes/no [yes]: yes\n Version for `p01.core` : 1.0.0\n The release p01.core-1.0.0 does not exist.\n Do you want to create it? yes/no [yes]: yes\n Version for `p01.web` : 1.0.0\n The release p01.web-1.0.0 does not exist.\n Do you want to create it? yes/no [yes]: yes\n\nThe next time you make a release, you can set the ``-n`` flag for\n``build-package`` to automatically guess the next version that should\nbe released. It does this by first looking for all the release tags\nof a given package and finding the last changed revision for the trunk\nof a given package. If any code for the given package was changed\nsince the last time it was released, it will bump the most minor\nversion number automatically. If no change has occured, it will\nchoose the latest existing release.\n\nYou can also use the ``-d`` flag to make ``build-package`` not prompt\nyou before creating a new release.\n\nIf you need to make a new release from a particular branch, you can\nuse the ``-b`` option. For example, if bug fixes have been made to the\nMyServer-1.x branch, we can create a new release using code from this\nbranch like this::\n\n $ build-package -c MyServer.cfg -nb MyServer-1.x\n\nWhen the new package versions are calculated, they will be versioned\nalong the 1.x line, even if you have since created 2.x releases, by\nanalyzing the name of the branch.\n\nCaveat when using ``-n`` and ``-d`` on a branch with a branchname ending\nwith the version number is that you'll need to have the package versions\nmatching the branch version.\nE.g. having a branch: ``branches/myserver-1.9`` will suppose packages like\n``p01.core-1.9.x`` and ``p01.web-1.9.x`` and so on.\nYou should be aware of this also when releasing packages from the trunk.\nMost probably you'll drive development on the trunk and branch out for a\nstable. In this case package versions on the branch should be kept inline.\n\n\nInstall a Released Project\n---------------------------\n\n``p01.build`` also comes with a very simple installation script that\ncan be used to quickly install any variant of the released project::\n\n $ deploy --help\n Usage: deploy [options]\n\n Options:\n -h, --help show this help message and exit\n -u URL, --url=URL The base URL at which the releases can be found.\n -p PROJECT, --project=PROJECT\n The name of the project to be installed.\n -V VARIANT, --variant=VARIANT\n The variant of the project to be installed.\n -v VERSION, --version=VERSION\n The version of the project to be installed.\n --directory=FOLDER Override installation target folder\n -l, --latest When specified, the latest version will be chosen.\n --username=USER The username needed to access the site.\n --password=PASSWORD The password needed to access the site.\n -b PATH, --buildout-path=PATH\n The path to the buildout executable.\n --quiet When specified, no messages are displayed.\n --verbose When specified, debug information is created.\n --timeout=TIMEOUT Socket timeout passed on to buildout.\n\nFor example, to install the latest Stage version of the ``MyServer`` project,\nyou would run:\n\n $ deploy -u https://pypi.projekt01.ch/++projects++/ -p MyServer -V Stage --latest\n\n\nCreating Helper Scripts\n-----------------------\n\nSometimes it can be a pain to remember what all the command line\noptions are that you need to pass for building your project.\nFortunately, it is really easy to create helper scripts that just set\nsome defaults for you.\n\nFor example, to create a build-myserver script, you would add the\nfollowing to a buildout configuration file::\n\n [uploads]\n recipe = p01.recipe.setup:mkdir\n path = ${buildout:directory}/parts/uploads\n\n [build-myserver]\n recipe = zc.recipe.egg\n eggs = p01.build\n scripts = build=build-myserver\n initialization =\n sys.argv[1:1] = ['-c', 'MyServer.cfg',\n '-o', '${buildout:directory}/parts/uploads']\n\nThe possibilities are endless!\n\nFootnotes\n=========\n\n.. [#ini] See http://en.wikipedia.org/wiki/INI_file\n.. [#webdav] See http://en.wikipedia.org/wiki/WebDAV\n\n\n=======\nCHANGES\n=======\n\n0.7.1 (2018-09-04)\n------------------\n\n- feature: added svn-trust-server-cert option for trust svn server certificate\n\n\n0.7.0 (2018-05-13)\n------------------\n\n- bugfix: adjust BeautifulSoup dependency, switch to beautifulsoup4\n\n\n0.6.0 (2018-02-10)\n------------------\n\n- feature: added uploadFormat build option for build zip or tar.gz release files\n Use the new uploadFormat option additional to the uploadType option in your\n project setup file. Use one of ``zip``, ``gztar``, ``bztar``, ``ztar`` or\n ``tar``. Note, there is only one format option allowed.\n\n\n0.5.1 (2015-08-26)\n------------------\n\n- feature: added option -s, --storage-path which defines a directory where we\n store the created files before upload to pypi, webdav etc. This prevents that\n all files get generated into the package root.\n\n- cleaup code, get rid of pkg_resources.parse_version deprecation message.\n Ported the parse_version method for now.\n\n- removed p01/build/install.py and move code to p01/build/deploy.py. Switch the\n entry point for deploy to deploy.py\n\n\n0.5.0 (2015-04-15)\n------------------\n\n- bugfix: parse given buildout parts content as is and only rstrip continue\n lines. This allows to use any content in parts like script content etc.\n without any intend troubles. The parse concept is similar and compatible with\n the one used in zc.buildout > 2.0\n\n- This package provides a product build, release and installation system based\n on package versions using zc.buildout. The core concept is taken from\n keas.build and provides the same configuration syntax. The main difference\n is that we don't setup the install script as ``install`` because there is a\n conflict with the gnu install script call on ubuntu (pycairo, python waf\n install) used by a popen recipe (p01.recipe.setup:popen). This implementation\n will offer the install script as a ``deploy`` entry_point. You can simply\n install the deploy script with ``easy_install p01.build`` on your server.\n For more information see p01/build/README.txt.\n\n- initial branch of keas.build 0.4.1\n",
"description_content_type": "",
"docs_url": null,
"download_url": "",
"downloads": {
"last_day": -1,
"last_month": -1,
"last_week": -1
},
"home_page": "https://pypi.org/pypi/p01.build",
"keywords": "Zope3 z3c p01 build release deploy install",
"license": "ZPL 2.1",
"maintainer": "",
"maintainer_email": "",
"name": "p01.build",
"package_url": "https://pypi.org/project/p01.build/",
"platform": "",
"project_url": "https://pypi.org/project/p01.build/",
"project_urls": {
"Homepage": "https://pypi.org/pypi/p01.build"
},
"release_url": "https://pypi.org/project/p01.build/0.7.1/",
"requires_dist": null,
"requires_python": "",
"summary": "A build system supporting application deploy and installation",
"version": "0.7.1"
},
"last_serial": 4237944,
"releases": {
"0.5.0": [
{
"comment_text": "",
"digests": {
"md5": "37cc8cd8b1968d921f82498c7aa890af",
"sha256": "f13383d01f9d79b19963f268aee7d4dbb810fff7714608f6d400258fff18f20c"
},
"downloads": -1,
"filename": "p01.build-0.5.0.zip",
"has_sig": false,
"md5_digest": "37cc8cd8b1968d921f82498c7aa890af",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 47394,
"upload_time": "2015-04-17T08:44:27",
"url": "https://files.pythonhosted.org/packages/42/27/22380a05d5778fe19c9ad5edcef5f51383aa252570b9b9bd436421493bf8/p01.build-0.5.0.zip"
}
],
"0.5.1": [
{
"comment_text": "",
"digests": {
"md5": "98904eef869035c591d98f271e61cd3b",
"sha256": "558aa16e03af28688dadf3495699660a18d9a6a9805c6547a9b240e353c0dd1c"
},
"downloads": -1,
"filename": "p01.build-0.5.1.zip",
"has_sig": false,
"md5_digest": "98904eef869035c591d98f271e61cd3b",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 48175,
"upload_time": "2015-08-26T05:16:48",
"url": "https://files.pythonhosted.org/packages/ec/b3/32378f1e6c5f762ae7e0aabaacab00c2f9e36271228d35b17a7aca88bdf6/p01.build-0.5.1.zip"
}
],
"0.6.0": [
{
"comment_text": "",
"digests": {
"md5": "3f0ce53f7831788ffd76aeb033c1bb53",
"sha256": "a0846e42fc6edcb3af4cd25a883fb8f9a20ecc851c756bc5e92243253f5c22e7"
},
"downloads": -1,
"filename": "p01.build-0.6.0.tar.gz",
"has_sig": false,
"md5_digest": "3f0ce53f7831788ffd76aeb033c1bb53",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 38552,
"upload_time": "2018-02-10T18:54:20",
"url": "https://files.pythonhosted.org/packages/d7/6f/9bd12091293d03579c9b951a05819a1087c369512b6e4b50e823d51f178c/p01.build-0.6.0.tar.gz"
}
],
"0.7.0": [
{
"comment_text": "",
"digests": {
"md5": "7a4b128cf649dc816ae2dc2b680cbc11",
"sha256": "3fcd7dc19686024188c591b4e2dcd55c023e9311cd7f90059dd32487a36f16ff"
},
"downloads": -1,
"filename": "p01.build-0.7.0.tar.gz",
"has_sig": false,
"md5_digest": "7a4b128cf649dc816ae2dc2b680cbc11",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 38699,
"upload_time": "2018-05-13T16:05:45",
"url": "https://files.pythonhosted.org/packages/44/fe/8d405cdf76d463c372d7abdaa9af01127412d59cb92228181c35afb67681/p01.build-0.7.0.tar.gz"
}
],
"0.7.1": [
{
"comment_text": "",
"digests": {
"md5": "a42e7bcea70023aa99adbf0b77878a73",
"sha256": "dcb6dd491eea5293d5c3f57f9b76bb53773a97133b6f5a11ebbe2bb79accc04e"
},
"downloads": -1,
"filename": "p01.build-0.7.1.tar.gz",
"has_sig": false,
"md5_digest": "a42e7bcea70023aa99adbf0b77878a73",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 41422,
"upload_time": "2018-09-04T14:50:33",
"url": "https://files.pythonhosted.org/packages/cf/52/62ac1088a6dccddb41a86fbab7ebba7a4d80e0412c401c9e4a2cf3381cd4/p01.build-0.7.1.tar.gz"
}
]
},
"urls": [
{
"comment_text": "",
"digests": {
"md5": "a42e7bcea70023aa99adbf0b77878a73",
"sha256": "dcb6dd491eea5293d5c3f57f9b76bb53773a97133b6f5a11ebbe2bb79accc04e"
},
"downloads": -1,
"filename": "p01.build-0.7.1.tar.gz",
"has_sig": false,
"md5_digest": "a42e7bcea70023aa99adbf0b77878a73",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 41422,
"upload_time": "2018-09-04T14:50:33",
"url": "https://files.pythonhosted.org/packages/cf/52/62ac1088a6dccddb41a86fbab7ebba7a4d80e0412c401c9e4a2cf3381cd4/p01.build-0.7.1.tar.gz"
}
]
}