[10/22] AMBARI-7138. Ambari RPM deals with jinja2 dependency incorrectly (aonishuk)
http://git-wip-us.apache.org/repos/asf/ambari/blob/658360a5/ambari-common/src/main/python/jinja2/docs/api.rst
--
diff --git a/ambari-common/src/main/python/jinja2/docs/api.rst
b/ambari-common/src/main/python/jinja2/docs/api.rst
deleted file mode 100644
index 3bf8a94..000
--- a/ambari-common/src/main/python/jinja2/docs/api.rst
+++ /dev/null
@@ -1,787 +0,0 @@
-API
-===
-
-.. module:: jinja2
-:synopsis: public Jinja2 API
-
-This document describes the API to Jinja2 and not the template language. It
-will be most useful as reference to those implementing the template interface
-to the application and not those who are creating Jinja2 templates.
-
-Basics
---
-
-Jinja2 uses a central object called the template :class:`Environment`.
-Instances of this class are used to store the configuration, global objects
-and are used to load templates from the file system or other locations.
-Even if you are creating templates from strings by using the constructor of
-:class:`Template` class, an environment is created automatically for you,
-albeit a shared one.
-
-Most applications will create one :class:`Environment` object on application
-initialization and use that to load templates. In some cases it's however
-useful to have multiple environments side by side, if different configurations
-are in use.
-
-The simplest way to configure Jinja2 to load templates for your application
-looks roughly like this::
-
-from jinja2 import Environment, PackageLoader
-env = Environment(loader=PackageLoader('yourapplication', 'templates'))
-
-This will create a template environment with the default settings and a
-loader that looks up the templates in the `templates` folder inside the
-`yourapplication` python package. Different loaders are available
-and you can also write your own if you want to load templates from a
-database or other resources.
-
-To load a template from this environment you just have to call the
-:meth:`get_template` method which then returns the loaded :class:`Template`::
-
-template = env.get_template('mytemplate.html')
-
-To render it with some variables, just call the :meth:`render` method::
-
-print template.render(the='variables', go='here')
-
-Using a template loader rather then passing strings to :class:`Template`
-or :meth:`Environment.from_string` has multiple advantages. Besides being
-a lot easier to use it also enables template inheritance.
-
-
-Unicode
-
-Jinja2 is using Unicode internally which means that you have to pass Unicode
-objects to the render function or bytestrings that only consist of ASCII
-characters. Additionally newlines are normalized to one end of line
-sequence which is per default UNIX style (``\n``).
-
-Python 2.x supports two ways of representing string objects. One is the
-`str` type and the other is the `unicode` type, both of which extend a type
-called `basestring`. Unfortunately the default is `str` which should not
-be used to store text based information unless only ASCII characters are
-used. With Python 2.6 it is possible to make `unicode` the default on a per
-module level and with Python 3 it will be the default.
-
-To explicitly use a Unicode string you have to prefix the string literal
-with a `u`: ``u'Hänsel und Gretel sagen Hallo'``. That way Python will
-store the string as Unicode by decoding the string with the character
-encoding from the current Python module. If no encoding is specified this
-defaults to 'ASCII' which means that you can't use any non ASCII identifier.
-
-To set a better module encoding add the following comment to the first or
-second line of the Python module using the Unicode literal::
-
-# -*- coding: utf-8 -*-
-
-We recommend utf-8 as Encoding for Python modules and templates as it's
-possible to represent every Unicode character in utf-8 and because it's
-backwards compatible to ASCII. For Jinja2 the default encoding of templates
-is assumed to be utf-8.
-
-It is not possible to use Jinja2 to process non-Unicode data. The reason
-for this is that Jinja2 uses Unicode already on the language level. For
-example Jinja2 treats the non-breaking space as valid whitespace inside
-expressions which requires knowledge of the encoding or operating on an
-Unicode string.
-
-For more details about Unicode in Python have a look at the excellent
-`Unicode documentation`_.
-
-Another important thing is how Jinja2 is handling string literals in
-templates. A naive implementation would be using Unicode strings for
-all string literals but it turned out in the past that this is problematic
-as some libraries are typechecking against `str` explicitly. For example
-`datetime.strftime` does not accept Unicode arguments. To not break it
-completely Jinja2 is returning `str` for strings that fit into ASCII and
-for everything else `unicode`:
-
- m = Template(u{% set a, b = 'foo', 'föö' %}).module
- m.a
-'foo'
- m.b
-u'f\xf6\xf6'
[10/22] AMBARI-7138. Ambari RPM deals with jinja2 dependency incorrectly (aonishuk)
http://git-wip-us.apache.org/repos/asf/ambari/blob/7c3ea59f/ambari-common/src/main/python/jinja2/docs/api.rst
--
diff --git a/ambari-common/src/main/python/jinja2/docs/api.rst
b/ambari-common/src/main/python/jinja2/docs/api.rst
deleted file mode 100644
index 3bf8a94..000
--- a/ambari-common/src/main/python/jinja2/docs/api.rst
+++ /dev/null
@@ -1,787 +0,0 @@
-API
-===
-
-.. module:: jinja2
-:synopsis: public Jinja2 API
-
-This document describes the API to Jinja2 and not the template language. It
-will be most useful as reference to those implementing the template interface
-to the application and not those who are creating Jinja2 templates.
-
-Basics
---
-
-Jinja2 uses a central object called the template :class:`Environment`.
-Instances of this class are used to store the configuration, global objects
-and are used to load templates from the file system or other locations.
-Even if you are creating templates from strings by using the constructor of
-:class:`Template` class, an environment is created automatically for you,
-albeit a shared one.
-
-Most applications will create one :class:`Environment` object on application
-initialization and use that to load templates. In some cases it's however
-useful to have multiple environments side by side, if different configurations
-are in use.
-
-The simplest way to configure Jinja2 to load templates for your application
-looks roughly like this::
-
-from jinja2 import Environment, PackageLoader
-env = Environment(loader=PackageLoader('yourapplication', 'templates'))
-
-This will create a template environment with the default settings and a
-loader that looks up the templates in the `templates` folder inside the
-`yourapplication` python package. Different loaders are available
-and you can also write your own if you want to load templates from a
-database or other resources.
-
-To load a template from this environment you just have to call the
-:meth:`get_template` method which then returns the loaded :class:`Template`::
-
-template = env.get_template('mytemplate.html')
-
-To render it with some variables, just call the :meth:`render` method::
-
-print template.render(the='variables', go='here')
-
-Using a template loader rather then passing strings to :class:`Template`
-or :meth:`Environment.from_string` has multiple advantages. Besides being
-a lot easier to use it also enables template inheritance.
-
-
-Unicode
-
-Jinja2 is using Unicode internally which means that you have to pass Unicode
-objects to the render function or bytestrings that only consist of ASCII
-characters. Additionally newlines are normalized to one end of line
-sequence which is per default UNIX style (``\n``).
-
-Python 2.x supports two ways of representing string objects. One is the
-`str` type and the other is the `unicode` type, both of which extend a type
-called `basestring`. Unfortunately the default is `str` which should not
-be used to store text based information unless only ASCII characters are
-used. With Python 2.6 it is possible to make `unicode` the default on a per
-module level and with Python 3 it will be the default.
-
-To explicitly use a Unicode string you have to prefix the string literal
-with a `u`: ``u'Hänsel und Gretel sagen Hallo'``. That way Python will
-store the string as Unicode by decoding the string with the character
-encoding from the current Python module. If no encoding is specified this
-defaults to 'ASCII' which means that you can't use any non ASCII identifier.
-
-To set a better module encoding add the following comment to the first or
-second line of the Python module using the Unicode literal::
-
-# -*- coding: utf-8 -*-
-
-We recommend utf-8 as Encoding for Python modules and templates as it's
-possible to represent every Unicode character in utf-8 and because it's
-backwards compatible to ASCII. For Jinja2 the default encoding of templates
-is assumed to be utf-8.
-
-It is not possible to use Jinja2 to process non-Unicode data. The reason
-for this is that Jinja2 uses Unicode already on the language level. For
-example Jinja2 treats the non-breaking space as valid whitespace inside
-expressions which requires knowledge of the encoding or operating on an
-Unicode string.
-
-For more details about Unicode in Python have a look at the excellent
-`Unicode documentation`_.
-
-Another important thing is how Jinja2 is handling string literals in
-templates. A naive implementation would be using Unicode strings for
-all string literals but it turned out in the past that this is problematic
-as some libraries are typechecking against `str` explicitly. For example
-`datetime.strftime` does not accept Unicode arguments. To not break it
-completely Jinja2 is returning `str` for strings that fit into ASCII and
-for everything else `unicode`:
-
- m = Template(u{% set a, b = 'foo', 'föö' %}).module
- m.a
-'foo'
- m.b
-u'f\xf6\xf6'
