Welcome to MuL App Engine Recipes’ documentation!

Contents:

MuL App Engine Recipes

https://readthedocs.org/projects/pip/badge/

Buildout recipes for App Engine.

App Engine SDK Recipe

Given a URL pointing to a Google App Engine Python SDK zip file, this recipe a) downloads the file and b) unzips the file and c) creates top-level Python scripts that invoke corresponding top-level SDK scripts.

Downloading uses and respects the options in the buildout.cfg‘s buildout section. Specifically, downloaded files are cached in the download-cache directory and files are never downloaded in offline mode.

The downloaded file (cached or not) is unzipped into the recipe’s part directory. The top level of the SDK directory is then scanned for Python scripts. For each SDK script a corresponding script is generated and placed in buildout’s bin-directory. The generated script simply invokes the SDK script, passing along arguments. Buildout’s relative-paths option is respected. Or, at least, it should be.

The list of generated scripts can be filtered using the scripts option. By default its value is ‘*’. If a ‘*’ appears anywhere in the list all scripts will be generated. Otherwise, only those scripts mentioned in the option (with or without a ‘.py’ extension) will be generated.

Options

scripts:A space-delimited list of Python script names or ‘*’. The default is ‘*’.
url:The url to the Google App Engine Python SDK zip file. Required.

Example

[sdk]
recipe = mul.recipe.appengine:sdk

url = \
    https://storage.googleapis.com/appengine-sdks/featured/google_appengine_1.9.21.zip

App Engine Lib Recipe

Given a list of eggs, this recipe a) computes their working set and then b) copies that working set into the specified lib-directory. (This recipe only copies eggs; it doesn’t download or install them.) The lib-directory is created each time the part is installed and deleted each time the part is uninstalled.

Eggs are copied unless they’re in the ignore-eggs list. The top-level packages of each egg are copied unless they’re in the ignore-packages list. The files and directories of each package are copied unless they’re in the ignore-files list. The ignore-files list supports globs. You must, of course, filter packages and files with care; eggs aren’t written to expect that kind of install-time surgery.

When an egg is copied its egg-info is also copied. The egg-info can be used for example by pkg_resources to locate package resources at runtime. The egg-info is copied in a manor similar to setup.py‘s --single-version-externally-managed install option; the egg-info directories are siblings of the package directories.

The eggs that are copied can be either zipped or unzipped.

Options

eggs:A newline-delimited list of eggs to copy. The default is an empty list.
ignore-eggs:A newline-delimited list of eggs to ignore when copying. The default is an empty list.
ignore-packages:
 A newline-delimited list of packages to ignore when copying. The default is an empty list.
ignore-files:A newline-delimited list of file globs to ignore when copying. The default is an empty list.
lib-directory:The directory to copy the egg-info and packages to. Required.

Example

[lib]
recipe = mul.recipe.appengine:lib

eggs =
    pyramid
    pyramid_debugtoolbar
ignore-eggs =
    MyEgg
ignore-packages =
    easy_install
    setuptools
    site
ignore-files =
    *.c
    *.h
    *.pyc
    *.pyo
    *.so
    test
    tests
    testsuite
lib-directory = develop/MyEgg/lib

Contributing

Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.

You can contribute in many ways:

Types of Contributions

Report Bugs

Report bugs at https://github.com/michaellenaghan/mul.recipe.appengine/issues.

If you are reporting a bug, please include:

  • Your operating system name and version.
  • Any details about your local setup that might be helpful in troubleshooting.
  • Detailed steps to reproduce the bug.

Fix Bugs

Look through the GitHub issues for bugs. Anything tagged with “bug” is open to whoever wants to implement it.

Implement Features

Look through the GitHub issues for features. Anything tagged with “feature” is open to whoever wants to implement it.

Write Documentation

MuL App Engine Recipes could always use more documentation, whether as part of the official MuL App Engine Recipes docs, in docstrings, or even on the web in blog posts, articles, and such.

Submit Feedback

The best way to send feedback is to file an issue at https://github.com/michaellenaghan/mul.recipe.appengine/issues.

If you are proposing a feature:

  • Explain in detail how it would work.
  • Keep the scope as narrow as possible, to make it easier to implement.
  • Remember that this is a volunteer-driven project, and that contributions are welcome :)

Get Started!

Ready to contribute? Here’s how to set up mul.recipe.appengine for local development.

  1. Fork the mul.recipe.appengine repo on GitHub.

  2. Clone your fork locally:

    $ git clone git@github.com:your_name_here/mul.recipe.appengine.git
    
  3. Install your local copy into a virtualenv. Assuming you have virtualenvwrapper installed, this is how you set up your fork for local development:

    $ mkvirtualenv mul.recipe.appengine
    $ cd mul.recipe.appengine/
    $ ./bin/python setup.py develop
    
  4. Create a branch for local development:

    $ git checkout -b name-of-your-bugfix-or-feature
    

    Now you can make your changes locally.

  5. When you’re done making changes, check that your changes pass flake8 and the tests, including testing other Python versions with tox:

    $ flake8 mul.recipe.appengine tests
    $ python setup.py test
    $ tox
    

    To get flake8 and tox, just pip install them into your virtualenv.

  6. Commit your changes and push your branch to GitHub:

    $ git add .
    $ git commit -m "Your detailed description of your changes."
    $ git push origin name-of-your-bugfix-or-feature
    
  7. Submit a pull request through the GitHub website.

Pull Request Guidelines

Before you submit a pull request, check that it meets these guidelines:

  1. The pull request should include tests.
  2. If the pull request adds functionality, the docs should be updated. Put your new functionality into a function with a docstring, and add the feature to the list in README.rst.
  3. The pull request should work for all supported Python versions. Check https://travis-ci.org/michaellenaghan/mul.recipe.appengine/pull_requests and make sure that the tests pass.

Credits

Developer

Michael Lenaghan <metamul -@- gmail.com>

Contributors

None yet. Why not be the first?

History

0.4.0 (2015-06-01)

  • Fixes & Simplifications.

0.3.0 (2015-05-31)

  • Configuration tweaks.

0.2.0 (2015-05-31)

  • Documentation tweaks.

0.1.0 (2015-05-31)

  • First release on PyPI.

License

Copyright (c) 2015, Michael Lenaghan. All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

  • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
  • Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
  • Neither the name of MuL App Engine Recipes nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.