python-Werkzeug/python-Werkzeug.spec

85 lines
3.0 KiB
RPMSpec

#
# spec file for package python-Werkzeug
#
# Copyright (c) 2014 SUSE LINUX Products GmbH, Nuernberg, Germany.
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
# upon. The license for this file, and modifications and additions to the
# file, is the same license as for the pristine package itself (unless the
# license for the pristine package is not an Open Source License, in which
# case the license is the MIT License). An "Open Source License" is a
# license that conforms to the Open Source Definition (Version 1.9)
# published by the Open Source Initiative.
# Please submit bugfixes or comments via http://bugs.opensuse.org/
#
Name: python-Werkzeug
Version: 0.9.6
Release: 0
Url: http://werkzeug.pocoo.org/
Summary: The Swiss Army knife of Python web development
License: BSD-3-Clause
Group: Development/Languages/Python
Source: http://pypi.python.org/packages/source/W/Werkzeug/Werkzeug-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-build
BuildRequires: python-Sphinx
BuildRequires: python-devel
BuildRequires: python-nose
BuildRequires: python-setuptools
Provides: python-werkzeug = %{version}
Obsoletes: python-werkzeug < %{version}
%if 0%{?suse_version} && 0%{?suse_version} <= 1110
%{!?python_sitelib: %global python_sitelib %(python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}
%else
BuildArch: noarch
%endif
%description
Werkzeug started as simple collection of various utilities for WSGI
applications and has become one of the most advanced WSGI utility
modules. It includes a powerful debugger, full featured request and
response objects, HTTP utilities to handle entity tags, cache control
headers, HTTP dates, cookie handling, file uploads, a powerful URL
routing system and a bunch of community contributed addon modules.
Werkzeug is unicode aware and doesn't enforce a specific template
engine, database adapter or anything else. It doesn't even enforce
a specific way of handling requests and leaves all that up to the
developer. It's most useful for end user applications which should work
on as many server environments as possible (such as blogs, wikis,
bulletin boards, etc.).
%package doc
Summary: Documentation for %{name}
Group: Documentation/Other
Requires: %{name} = %{version}
%description doc
Documentation and examples for %{name}.
%prep
%setup -q -n Werkzeug-%{version}
sed -i "s/\r//" LICENSE # Fix wrong EOL-encoding
sed -i "1d" examples/manage-{i18nurls,simplewiki,shorty,couchy,cupoftee,webpylike,plnt,coolmagic}.py # Fix non-executable scripts
%build
python setup.py build
cd docs && make html && rm -rf _build/html/.buildinfo # Build HTML Documentation
%install
python setup.py install --prefix=%{_prefix} --root=%{buildroot}
%files
%defattr(-,root,root,-)
%doc AUTHORS LICENSE CHANGES
%{python_sitelib}/*
%files doc
%defattr(-,root,root,-)
%doc docs/_build/html examples
%changelog