File python-addons.spec of Package python-addons

#
# spec file for package python-addons (Version 0.6)
#
# Copyright 2008 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.

# norootforbuild

%define real_name AddOns

Name:           python-addons
Version:        0.6
Release:        0
License:        PSF or ZPL
Source:         %{real_name}-%{version}.tar.gz
Group:          Development/Libraries/Python
Summary:        Dynamically extend other objects with AddOns (formerly ObjectRoles)
BuildRoot:      %{_tmppath}/%{name}-%{version}-build
Autoreqprov:    on
Url:            http://pypi.python.org/pypi/AddOns

BuildRequires:  python-setuptools
%py_requires

%description
(NEW in version 0.6: the``Registry`` base class, and the ClassAddOn.for_frame() classmethod.)

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.

AddOn classes are like dynamic mixins, but with their own private attribute and method namespaces. A concern implemented using add-ons can be added at runtime to any object that either has a writable __dict__ attribute, or is weak-referenceable.

AddOn classes are also like adapters, but rather than creating a new instance each time you ask for one, an existing instance is returned if possible. In this way, add-ons can keep track of ongoing state. For example, a Persistence add-on might keep track of whether its subject has been saved to disk yet:

%prep
%setup -q -n %real_name-%version

%build
python setup.py build

%install
python setup.py install --prefix=%_prefix --root=%buildroot --record-rpm=filelist

%clean
rm -rf %buildroot

%files -f filelist
%defattr(-,root,root)
%doc 
#PKG-INFO docs


%changelog
* Wed Mar 04 2009 cfarrell1980@gmail.com
- Initial import