File python-peak-util-addons.spec of Package python-peak-util-addons

%{!?python_sitelib: %define python_sitelib %(%{__python} -c "from distutils.sysconfig import get_python_lib; print get_python_lib()")}

%define packagename AddOns

Name:           python-peak-util-addons
Version:        0.6
Release:        1%{?dist}
Summary:        Dynamically extend other objects with AddOns

Group:          Development/Languages
License:        PSF or ZPL
URL:            http://pypi.python.org/pypi/AddOns
Source0:        http://pypi.python.org/packages/source/A/%{packagename}/%{packagename}-%{version}.zip
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

BuildRequires:  python-devel
BuildRequires:  python-setuptools
BuildRequires:  unzip

Requires:       python-decoratortools >= 1.5

%description
In any sufficiently-sized application or framework, it's common to end up
lumping a lot of different concerns into the same class.  For example, you may
have business logic, persistence code, and UI all jammed into a single class.
Attribute and method names for all sorts of different operations get shoved
into a single namespace -- even when using mixin classes.

Separating concerns into different objects, however, makes it easier to write
reusable and separately-testable components.  The AddOns package
(``peak.util.addons``) lets you manage concerns using ``AddOn`` classes.

%prep
%setup -q -n %{packagename}-%{version}

%build
export CFLAGS="$RPM_OPT_FLAGS"
python setup.py build

%install
#rm -rf %{buildroot}
python setup.py install --prefix=%{_prefix} --root=$RPM_BUILD_ROOT --record-rpm=INSTALLED_FILES

%clean
rm -rf %{buildroot}

%files -f INSTALLED_FILES
%defattr(-,root,root)
#%doc CHANGES LICENSE README TODO


%changelog
* Sun Aug 12 2008 Luke Macken <lmacken@redhat.com> - 0.6-1
- Initial package for Fedora