Version + Patches = Buildout

Total Page:16

File Type:pdf, Size:1020Kb

Version + Patches = Buildout Understanding Buildout In SlapOS Details Buildout is a Python-based system for creating, assembling and deploying applications from multiple parts, which may or not be Python-based. It allows to create Buildout configuration files from which the exact same software can (later) be reproduced. Buildout originated from the Zope/Plone community to automate the deployment of customized instances of their own software. Lead by Jim Fulton (CTO of Zope Corporation), Buildout has become a stable and mature software over the years (source code). Buildout is an integral part of SlapOS. The following design document explains what Buildout is and how Buildout files are used in SlapOS before discussing advantages and alleged shortcomings of Buildout. For more information on the way Buildout is integrated in the SlapOS ecosystem, refer to the SlapOS architecture introduction. Table of Content Introducing Buildout Simple Buildout Example Buildout.cfg Walkthrough Advantages of Buildout Details Introducing Buildout Details Buildout is a tool for automating software assembly including running build tools to build software and applying software and templates to generate configuration files and scripts Buildout is applicable to all phases of software development and in production deployment. It is based on three core principles: Repeatability, Componentization and Automation. slapos.buildout (Gitlab repository) is a fork of zc.buildout maintained by SlapOS which includes various fixes that may or may not have been merged back into Buildout upstream (see Buildout developer guidelines for how to contribute to Buildout). Why Buildout? Details Buildout is used in SlapOS to define what software to install and instantiate on a node and is therefore key to the architecture of SlapOS. Buildout is one answer to the fact that there will never be a possible software standard in the cloud: every system gets patched. From large scale production systems operating in the cloud or privately to single components like relational databases. Patching is required to meet performance requirements of given applications as soon as data volume grows. If a cloud operating system does not provide the possibility to patch any of its software components, it is simply unusable for large scale production environments. SlapOS is usable because its definition of what it considers a software is based on the possibility of patching any dependent software component - which is done using Buildout. Version + Patches = Buildout Details It is often assumed giving a name to a software (like "KVM" or "MySQL") is sufficient. While it actually is for many cases (and SlapOS provides aliases "KVM" and "MySQL" which link to explicit Buildout configurations), the reality is not as straightforward. For example, some releases of KVM support NBD protocol over IPv6 while some don't. Some support Sheepdog distributed block storage while others don't. Some support CEPH distributed block storage and so on. Most users using KVM do not care about IPv6, Sheepdog or CEPH, but users of SlapOS need IPv6 support to access NBD which at the time of writing is only available as a patch. A resilient storage based on Sheepdog was only made available from version 0.13 and CEPH support requires another patch. For MySQL, the above possibilities multiply with multiple sources from the official one M( ySQL), MariaDB, Percona InnoDB or Cubrid, which is not MySQL but claims to be 90% compatible. Each source has different versions and default compilation options. Maintainers of large scale applications know very well that the performance of applications can be seriously impacted by subtle changes to the SQL optimizer so the possibility to choose which source of MySQL to use and which patches to apply are crucial when running enterprise applications. Details As the number of possibilities to patch and the specific user requirements can be close to infinite, the easiest way to know which software is actually being installed on a SlapOS node is simply to list where the original source code was obtained from and which patches were applied. This is exactly what Buildout does with a few lines of configuration. It also eliminates the process of distributing binary packages on a wide range of hardware architectures thanks to a trusted, distributed caching mechanism which does not even use a centralized signature. Simple Buildout Example Details A Buildout configuration is based on a .cfg file called the buildout profile. This profile may contain multiple sections, called parts, starting with the [part name] syntax. The first part is always called [buildout] and allows to define the list of other parts to execute. Each other part is executed by a python script called a recipe. If the recipe is not available in the system, it will automatically be downloaded by Buildout. Bootstrapping Buildout > mkdir buildoutenv && cd buildoutenv > vi buildout.cfg > curl -s htp://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstra p.py | python -S - Generated script 'bin/buildout'. > ./bin/buildout > ls eggs ipython-0.10.1-py2.6.egg zc.recipe.egg-1.3.2-py2.6.egg Details Buildout has to be bootstrapped in order to allow it to initialize the deployment environment. Once done, ab in/buildout binary becomes available and has to be run to execute the respective profile. The executable should be available to run this program in the bin directory (bin/ipython). Buildout.cfg // buildout.cfg [buildout] parts = demo [demo] recipe = zc.recipe.egg eggs = ipython Details In this example, the recipe zc.recipe.egg is used to install python packages (called eggs). When executed, this recipe will download the egg called 'ipython' (along with its dependencies) and install it. Compiling Binaries // buildout.cfg [buildout] parts = demo [demo] recipe = hexagonit.recipe.cmmi url = htp://gondor.apana.org.au/~herbert/dash/fles/dash-0.5.6.1.tar.gz Details Buildout can be used to compile C/C++ code using gcc. To do this the recipeh exagonit.recipe.cmmi can be used. It takes the URL of the source package as parameter. When executed, the source package will be automatically downloaded, extracted, configured, compiled and installed in the parts directory. [...] > ./bin/buildout > ls parts/demo/bin dash Running Multiple Parts // buildout.cfg [buildout] parts = ipython dash [dash] recipe = hexagonit.recipe.cmmi url = htp://gondor.apana.org.au/~herbert/dash/fles/dash-0.5.6.1.tar.gz [ipython] recipe = zc.recipe.egg eggs = ipython Details Of course multiple parts can configured in the profile. Their execution order follows the parts parameter (ipython is executed before dash). Buildout.cfg Walkthrough Details The following section will walk through a more complex Buildout.cfg file explaining how the different sections will be used to build a specific software release. For more information on Buildout, please refer to the Buildout getting started page. You can find additional examples of SlapOS component Buildout configuration files in theS lapOS repository component folder. These components are used to build more complex software (Buildout files can use other Buildout files)N. ote, that while the following file may be outdated, it still explains many concepts and thus serves as a good example of describing how SlapOS uses Buildout. The file being used is an old buildout.cfg file for SlapOS (version 0.69). Once you have read through this section, you could compare this file to the latest version (version 1.0.63) to see whether you can apply the principles to a different but related file. What is Buildout (1) [buildout] extends = ../../stack/shacache-client.cfg ../lxml-python/buildout.cfg ../python-2.7/buildout.cfg parts = slapos find-links = http://www.nexedi.org/static/packages/source/slapos.buildout/ versions = versions Details The first section of a Buildout is named [buildout]. It defines which software is going to be built and how. In the case of SlapOS Buildout we can first see that SlapOS Buildout extends existing Buildout definitions, namely shacache-client, lxml-python and python2.7 itself. It then defines the parts variable which lists the sections which are going to be required as part of the build process. A section in a Buildout file is defined by a name inside square brackets. [buildout], [lxml-python], [slapos] and [versions] are the four sections of this Buildout file. The find-links variable defines a repository of eggs. Eggs is a standard distribution mechanism for python packages. Buildout itself is written in python and can be extended using python language and eggs. Since not all eggs are published in Python Packing Index (PyPI), it is sometimes necessary to provide additional repositories of eggs. One should note here that the find-links variable is a generic variable used by python setuptools, the python module in charge of managing python distributions. Details In our case we use this find-links variable to override the default Buildout distribution with SlapOS's own Buildout. SlapOS extends Buildout solving minor issues (support of distributed network caching and small bug fixes), which are not yet integrated in the default Buildout. However, since Buildout profiles are self contained, it is possible to specify which version of Buildout to use (in the [versions] section discussed below) and where to find that version through find-links, as long as this version of Buildout made by SlapOS is published somewhere. The versions variable specifies which Buildout section is used to define specific versions of python distributions (eggs). Being able to specify the version of each egg is required in order to make sure that the exact same software is installed on every node of a distributed cloud and that no uncontrolled upgrade will happen. The allow-hosts variable is used to specify explicitly which sources of python distributions (eggs) are accepted. It is a useful variable to make sure that the Buildout process does not get interrupted by lost connectivity to unreliable sites containing python distributions.
Recommended publications
  • Zope Documentation Release 5.3
    Zope Documentation Release 5.3 The Zope developer community Jul 31, 2021 Contents 1 What’s new in Zope 3 1.1 What’s new in Zope 5..........................................4 1.2 What’s new in Zope 4..........................................4 2 Installing Zope 11 2.1 Prerequisites............................................... 11 2.2 Installing Zope with zc.buildout .................................. 12 2.3 Installing Zope with pip ........................................ 13 2.4 Building the documentation with Sphinx ............................... 14 3 Configuring and Running Zope 15 3.1 Creating a Zope instance......................................... 16 3.2 Filesystem Permissions......................................... 17 3.3 Configuring Zope............................................. 17 3.4 Running Zope.............................................. 18 3.5 Running Zope (plone.recipe.zope2instance install)........................... 20 3.6 Logging In To Zope........................................... 21 3.7 Special access user accounts....................................... 22 3.8 Troubleshooting............................................. 22 3.9 Using alternative WSGI server software................................. 22 3.10 Debugging Zope applications under WSGI............................... 26 3.11 Zope configuration reference....................................... 27 4 Migrating between Zope versions 37 4.1 From Zope 2 to Zope 4 or 5....................................... 37 4.2 Migration from Zope 4 to Zope 5.0..................................
    [Show full text]
  • The Hitchhiker's Guide to Packaging" Documentation
    The Hitchhiker’s Guide to Packaging" Documentation Release 1.0 Tarek Ziadé Sep 27, 2017 Contents 1 Table of Contents 3 1.1 Quick Start................................................3 1.2 Introduction to Packaging........................................5 1.3 Installing the Package Tools.......................................9 1.4 Using Packages.............................................. 12 1.5 Creating a Package............................................ 13 1.6 Contribute Your Package to the World.................................. 18 1.7 Virtual Environments........................................... 23 1.8 Specifications............................................... 24 1.9 Advanced Topics............................................. 28 1.10 Future of Packaging........................................... 28 1.11 Glossary................................................. 28 1.12 Credits.................................................. 31 1.13 License.................................................. 31 2 Indices and tables 33 Bibliography 35 i ii The Hitchhiker’s Guide to Packaging" Documentation, Release 1.0 Warning: This document is currently under development. Thank you for your interest. Contents 1 The Hitchhiker’s Guide to Packaging" Documentation, Release 1.0 2 Contents CHAPTER 1 Table of Contents Quick Start Here’s how to create a new project, which we’ll call TowelStuff. 1. Lay out your project The smallest python project is two files. A setup.py file which describes the metadata about your project, and a file containing Python code to implement the functionality of your project. In this example project we are going to add a little more to the project to provide the typical minimal layout of a project. We’ll create a full Python package, a directory with an __init__.py file, called towelstuff/. This anticipates future growth as our project’s source code is likely to grow beyond a single module file. We’ll also create a README.txt file describing an overview of your project, and a LICENSE.txt file containing the license of your project.
    [Show full text]
  • Create Book' Link = 'Mkbook' Mclass = 'Nav Buttons'
    Grok 4 Noobs. P R Sephton Grok 4 Noobs. A gentle introduction to using the Grok web framework 2 A gentle introduction to using the Grok web framework Table of Contents: 1: What does Grok do particularly well? ... [7] 1.1: What are the nicest things about Zope & Grok? ... [10] 2: Grok & Zope in a Nutshell ... [13] 3: The Compulsory Part about Installing Grok ... [19] 3.1: Installing Grok from Github ... [21] 3.2: Installation Notes - older projects ... [22] 4: A short introduction to the Zope Component Architecture ... [24] 4.1: The Z-Object Publishing Environment ... [29] 4.2: Interfaces compared to Abstract Bases ... [30] 4.2.1: Interfaces vs. Inheritence: A Real World Example ... [33] 4.3: Traversal and the Context ... [39] 4.4: The amazingly useful Utility ... [41] 4.5: Events Mechanism ... [42] 4.5.1: A quick megrok.rdb (SQLAlchemy) setup howto ... [44] 4.6: Extending existing objects with Annotations ... [46] 5: Designing a site, defining it's layout and implementing the code ... [47] 5.1: How to make applications with Grok ... [49] 5.1.1: Modeling data in an application ... [53] 5.1.1.1: Notes on multithreading ... [55] 5.1.1.2: The Scope of models in Traversal ... [57] 5.1.1.3: Rules of Persistence ... [58] 5.1.1.4: User Session Management ... [59] 5.1.2: Defining an Article and the Application ... [60] 5.1.3: HTML Re-use and site layout ... [62] 5.1.3.1: Macros: an alternative way to re-use HTML ... [67] 5.1.3.2: The full source for the layout.py module ..
    [Show full text]
  • Zope Project and Community Documentation
    Zope Project and Community Documentation The Zope developer community Jun 21, 2021 Contents 1 The World of Zope 3 1.1 Frameworks...............................................3 1.2 Databases.................................................4 1.3 Application Servers...........................................4 1.4 Tools...................................................4 2 Documentation 5 2.1 Documentation..............................................5 3 Community 7 3.1 Community................................................7 3.2 Developer Information..........................................8 i ii Zope Project and Community Documentation Zope is a free and open source web application server written in the object-oriented programming language Python. Since its release in 1998, Zope continues to grow into many distinct applications, frameworks, libraries and tools. The World of Zope highlights the most important components. Zope community projects are hosted in the Zope Foundation organization on GitHub. Contents 1 Zope Project and Community Documentation 2 Contents CHAPTER 1 The World of Zope A Bit of History In 1996 Jim Fulton, now Zope Corporation CTO, was drafted to teach a class on common gateway interface (CGI) programming, despite not knowing very much about the subject. CGI programming is a commonly-used web development model that allows developers to construct dynamic web sites. Traveling to the class, Jim studied all the existing documentation on CGI. On the way back, Jim considered what he didn’t like about traditional CGI- based programming environments. From these initial musings the core of Zope was written while flying back from the CGI class. Zope Corporation (then known as Digital Creations) went on to release three open-source software packages to support web publishing: Bobo, Document Template, and BoboPOS. These packages were written in a language called Python, and provided a web publishing facility, text templating, and an object database, respectively.
    [Show full text]
  • Easybuild: Building Software with Ease
    EasyBuild: Building Software With Ease. Kenneth Hoste, Jens Timmerman, Andy Georges, Stijn De Weirdt HPC team – Unit ICT infrastructure (DICT) – Ghent University Krijgslaan 281, building S9, 9000 Gent, BELGIUM E-mail: fkenneth.hoste, jens.timmerman, andy.georges, [email protected] Abstract—Maintaining a collection of software installations for • Incompleteness. For example, only compilation in the a diverse user base can be a tedious, repetitive, error-prone and source directory is supported and it is a hassle to actually time-consuming task. Because most end-user software packages install the executables, libraries and include files, etc. for an HPC environment are not readily available in existing OS package managers, they require significant extra effort from the • Non-standard procedure. Installation procedures are often user support team. Reducing this effort would free up a large far more involved than a sequence of configure, build and amount of time for tackling more urgent tasks. install steps. For example, the installation procedure can In this work, we present EasyBuild, a software installation be interactive, i.e., requiring human intervention during framework written in Python that aims to support the various the configuration and installation. installation procedures used by the vast collection of software packages that are typically installed in an HPC environment – • Custom-built scripts. On various occasions, custom shell catering to widely different user profiles. It is built on top of scripts need to be used, as opposed to a set of standard existing tools, and provides support for well-established installa- tools such as configure, make, cmake, etc. tion procedures. Supporting customised installation procedures • Hard-coded parameters.
    [Show full text]
  • Grok Community Docs Documentation Release 1.2
    Grok Community Docs Documentation Release 1.2 2010-11, The Grok Community November 16, 2011 CONTENTS 1 About the grok documentation3 1.1 Introduction...............................................3 1.2 Building the docs.............................................3 2 Data Access 5 2.1 Acess content in the static directory from Python code.........................5 2.2 Indexing and Searching Objects in the ZODB..............................6 2.3 Basic ORM with megrok.rdb and SQLAlchemy............................ 11 2.4 Grok ORM with Storm.......................................... 18 2.5 How I Got Grok Talking To CAS.................................... 22 2.6 Navigating To Transient Objects Tutorial................................ 25 2.7 Create simple 1:2 relationship with Megrok.rdb and SqlAlchemy (over MySql)............ 36 2.8 Understanding default values for object database backed attributes................... 41 3 Security and Authentication 45 3.1 Authentication with Grok........................................ 45 3.2 Authentication and authorization in Grok................................ 48 4 Views, Templating, Client Side 55 4.1 Fanstatic resources............................................ 55 4.2 Using a KSS plugin for Drag-and-Drop................................. 56 4.3 Using z3x.form with Grok........................................ 59 4.4 Traversing subpaths in views....................................... 61 4.5 Adding AJAX to Grok with KSS.................................... 63 4.6 Automatic Form Generation......................................
    [Show full text]
  • To Download the PDF of My Presentation
    VA DERS (Q: What does it say?) VA DERS VA DERS (A: ªSpace Invadersº) am U us am U us (A: ªAmbi guousº) convention — configuration convention — configuration (A: ªConvention ov er configurationº) Welcome! A Grok Talk Brandon Craig Rhodes November 2007 What©s a convention? Conventions are traditionally extras. Conventions begin as optional practices to keep code sane “We always capitalize the names of classes in the code we write for this department.” “If you have a class Foo, name its corresponding page template foo.pt.” “We're putting cover sheets on all the TPS reports before they go out.” What if ... ? What if your web framework used conventions rather than config files? A simple example: View “Index” app.config <configure view=”index” class=”Index” template= “index.pt” /> index.pt <html> <body> <h1>Title</h1> </body></html> A class you've View written “Index” app.config <configure view=”index” The configuration class=”Index” template= file you need to “index.pt” hook them up! /> index.pt A page template <html> <body> <h1>Title</h1> you've written </body></html> Conventions are traditionally ignored by the computer But, what if ... ? What if the framework assumed, in the absence of other configuration, that Index goes with index.pt? Result: View “Index” All explicit configuration has disapperaed index.pt <html> <body> <h1>Title</h1> </body></html> Advantages Ensue! Advantages of CoC: 1. Less repetition Advantages of CoC: 1. Less repetition 2. Conventions get used, because they matter Advantages of CoC: 1. Less repetition 2. Conventions
    [Show full text]
  • Buildout Release 1.2.1
    Buildout Release 1.2.1 Jim Fulton Nov 20, 2017 Contents 1 Screencasts 1 1.1 A Brief Introduction to Buildout.....................................1 1.2 Using buildout to install Zope and Plone................................1 2 Talks 3 2.1 How AlterWay releases web applications using zc.buildout.......................3 2.2 Buildout for pure Python projects....................................3 2.3 Buildout lightning talk..........................................3 2.4 Delivering egg-based applications with zc.buildout, using a distributed model.............3 3 Slides 5 3.1 Django & Buildout............................................5 3.2 Delivering applications with zc.buildout and a distributed model....................5 3.3 Buildout and Plone............................................5 3.4 Python eggs, zc.buildout, zopeproject and zope3............................5 3.5 Reaching Deployment Nirvana Using Buildout.............................5 4 What people says about Buildout ?7 5 Overview of the Installation Process9 6 Directory Structure of a Buildout 11 7 Use Case - A Single Module 15 8 Buildout Documentation 17 8.1 Getting Started.............................................. 17 8.2 Tutorials................................................. 17 8.3 Creating Recipes............................................. 17 8.4 List of Recipes.............................................. 17 8.5 Links................................................... 18 9 Buildout Tutorial 19 9.1 What is zc.buildout?..........................................
    [Show full text]
  • Versidad Autonoma De Bucaramanga Unab
    COMPARACION DEL DESARROLLO DE UN APLICATIVO WEB ENTRE LOS LENGUAJES DE PROGRAMACION PYTHON Y JAVA ANDRES FELIPE FOGLIA ARDILA UNIVERSIDAD AUTONOMA DE BUCARAMANGA UNAB FACULTAD DE INGENIERIA DE SISTEMAS GRUPO PRISMA LINEA DE TECNOLOGIA Y SOCIEDAD BUCARAMANGA 2014 COMPARACION DEL DESARROLLO DE UN APLICATIVO WEB ENTRE LOS LENGUAJES DE PROGRAMACION PYTHON Y JAVA ANDRES FELIPE FOGLIA ARDILA ANTEPROYECTO DE PROYECTO DE GRADO DIRECTOR DEL PROYECTO FREDDY MENDEZ ORTIZ , RENE LOBO QUINTERO DOCENTES DE LA FACULTAD DE INGENIERIA DE SISTEMAS UNIVERSIDAD AUTONOMA DE BUCARAMANGA UNAB FACULTAD DE INGENIERIA DE SISTEMAS GRUPO PRISMA LINEA DE TECNOLOGIA Y SOCIEDAD BUCARAMANGA 2014 CONTENIDO 1. Planteamiento del problema y justificación 2. Objetivos 3. Antecedentes 4. Estado del Arte 5. Marco teórico 5.1 Tecnología Java 5.2 Aplicaciones web en Java 5.3 Java Server Pages Technology 5.4 Tecnología Python 5.5 Desarrollo web en Python 6. Diseño metodológico 7. Informe Final 8. Evaluación del modelo de caracterización del aplicativo web 9. Conclusiones 10. Bibliografía 11. Anexos 11.1 QSOS 11.2 Modelo de caracterización del aplicativo web 1. PLANTEAMIENTO DEL PROBLEMA Y JUSTIFICACION En los últimos años se ha venido escuchando sobre Python un lenguaje de programación cada vez más conocido entre los programadores de todo el mundo por su elegante sintaxis, fácil manera de leer además de su gran facilidad que hace que programar no sea complicado, se dice también que este lenguaje va a ser el más utilizado y con el que más se va a trabajar en un futuro no muy lejano. Todas estas razones hacen pensar en por que no empezar a utilizar este lenguaje y para poder saber si todo esto es verdad se va a trabajar con él y hacer un aplicativo de las misma forma que se hace con la tecnología Java.
    [Show full text]
  • Presentation
    open-emv.com The Team Roadmap • Introduction • Solution Overview • Energy Efficiency 101 • Site Tour • Under the Hood • Basic Machine Configuration (AMIs) • Software Configuration • Database Structure • The Web Application The Solution User's Browser jQuery OpenLayers Issue Tracking VCS (FogBugz) (beanstalk) User AWS EC2 m2.xlarge c1.medium (high-memory) (high-CPU) Database Applications Front-End Applications ZEO Zope Client Apache Zope Object Database Server Zope Client Zope Client PG Django PostgreSQL Database Bouncer (mod_wsgi) monitoring monitoring Development Machine zc.buildout mr.developer m1.small Monitoring Dashboard Developer Why CA Energy Efficiency? World Leader • 1.5 Million Jobs • $45 Billion in Payroll How does that compare to the rest of the U.S? California... • ... spends billions less on Electricity • ... has a ratio of GDP to Energy Consumed 68% higher • ... residents, per capita, pay lower utility bills !"#$%&'()*+(,()-+()./0'-,1)./023)4()&5)&-)*(,()$6)(7.&('-)$6)8$2&5/,'&$9:) ;))<9)=/(2)>(,,1?)@('-0,().$A&-$2&6-?)5/0'3(,)/5)=(B-)CD) Energy Efficiency and EMV How Does CA do Energy Efficiency? • CPUC established EE program cycle length and funding level • CPUC provides $ to utilities to implement EE Programs • Utilities report program accomplishments to CPUC How Does CA do Energy Efficiency? • CPUC hires independent EMV contractors to independently evaluate utility savings claims • CPUC awards $ to the utilities based on savings accomplishments • CPUC releases data publicly via website Rinse and Repeat Roadmap • Introduction
    [Show full text]
  • BUILDOUT Quick Reference
    Six Feet Up BUILDOUT Quick Reference Configuration (continued) Vocabulary buildout - A set of parts that describe how to assemble an application Clone a part using macros part - A set of options that allow you to build a piece of the application recipe - The software used to create a part based off of its options [original] option1 = foo Getting Started With a Plone Buildout [clone] You can add a default.cfg into your $HOME/.buildout directory to set up some user <= original option2 = bar defaults for any part of the buildout. You will have to manually create each of the directories shown here: Now the cloned part has option 1 and 2. [buildout] eggs-directory = /path/to/home/.buildout/eggs Assignments download-cache = /path/to/home/.buildout/downloads zope-directory = /path/to/home/.buildout/zope Assignments give you the ability to set section options via the command line. extends-cache = /path/to/home/.buildout/extends Assignments are in the form of: NOTE: These only provide defaults, they do not override settings in your buildout! section_name:option_name=value How to get started with a Plone buildout: Here are some examples: To start from scratch, you can use the ZopeSkel collection of templates: Set the log-level of the buildout section (This is equivalent to bin/buildout -vvvvv): $ easy_install -U ZopeSkel $ paster create -t plone4_buildout $ bin/buildout buildout:log-level=50 This will ask you a series of questions about your new buildout. Turn on debug mode for the instance: Once you have your buildout, you can now bootstrap it: $ bin/buildout instance:debug-mode=on $ cd path/to/buildout $ python2.6 bootstrap.py $ bin/buildout Links Now you have everything you’ll need to start your site (assuming the part names are zeoserver and instance).
    [Show full text]
  • Bluebream Documentation Release 1.0A4
    BlueBream Documentation Release 1.0a4 Zope Foundation March 10, 2010 CONTENTS 1 Introduction 3 1.1 Overview.................................................3 1.2 Join our community...........................................4 1.3 Brief history...............................................4 1.4 More about the project..........................................5 1.5 Organization of the documentation...................................5 1.6 Thanks..................................................6 2 What’s New ? 9 2.1 What’s new in BlueBream 1.0 ?.....................................9 3 Getting Started 129 3.1 Introduction............................................... 129 3.2 Preparations............................................... 129 3.3 Installation................................................ 130 3.4 Creating a sample project........................................ 130 3.5 Building the application......................................... 132 3.6 Basic usage................................................ 133 3.7 Package directory structure....................................... 134 3.8 Example 1: Hello World without page template............................. 136 3.9 Example 2: Hello World with page template.............................. 137 3.10 Example 3: A dynamic hello world................................... 138 3.11 Conclusion................................................ 139 4 Concepts and Technologies 141 4.1 Concepts................................................. 141 4.2 Technologies..............................................
    [Show full text]