%define upstream_name    MooseX-Role-BuildInstanceOf
%define upstream_version 0.08

Name:       perl-%{upstream_name}
Version:    %perl_convert_version %{upstream_version}
Release:    %mkrel 10

Summary:    Less Boilerplate when you need lots of Instances
License:    GPL+ or Artistic
Group:      Development/Perl
Url:        https://metacpan.org/release/%{upstream_name}
Source0:    https://cpan.metacpan.org/modules/by-module/MooseX/%{upstream_name}-%{upstream_version}.tar.gz

BuildRequires: perl(Class::MOP)
BuildRequires: perl(ExtUtils::MakeMaker) >= 6.300.0
BuildRequires: perl(List::MoreUtils)
BuildRequires: perl(List::Util)
BuildRequires: perl(Moose)
BuildRequires: perl(Moose::Role)
BuildRequires: perl(Moose::Util::TypeConstraints)
BuildRequires: perl(MooseX::Iterator)
BuildRequires: perl(MooseX::Role::Parameterized) >= 0.130.0
BuildRequires: perl(MooseX::Types::Path::Class)
BuildRequires: perl(Perl6::Junction)
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Test::More)
BuildRequires: perl(strict)
BuildRequires: perl(warnings)
BuildArch:  noarch

%description
There can often be a tension between coding for flexibility and for future
growth and writing code that is terse, to the point, and solves the
smallest possible business problem that is brought to you. Writing the
minimum code to solve a particular problem has merit, yet can eventually
leave you with an application that has many hacky modifications and is hard
to test in an isolated manner. Minimum code should not imply minimum
forward planning or poorly tested code.

For me, doing the right thing means I need to both limit myself to the
smallest possible solution for a given business case, yet make sure I am
not writing CODE that is impossible to grow over time in a clean manner.
Generally I attempt to do this by clearly separating the problem domains
under a business case into distinct classes. I then tie all the functional
bits together in the loosest manner possible. the Moose manpage makes this
easy, with its powerful attribute features, type coercions and Roles to
augment classical inheritance.

Loose coupling and deep configurability work well with inversion of control
systems, like the Bread::Board manpage or the IOC built into the the
Catalyst manpage MVC framework. It helps me to defer decisions to the
proper authority and also makes it easier to test my logic, since pieces
are easier to test independently.

%prep
%setup -q -n %{upstream_name}-%{upstream_version}

%build
%{__perl} Makefile.PL INSTALLDIRS=vendor

%make_build

%check
%make_build test

%install
%make_install

%files
%doc Changes LICENSE META.json META.yml README
%{_mandir}/man3/*
%perl_vendorlib/*

%changelog
* Sun Mar 20 2022 umeabot <umeabot> 0.80.0-10.mga9
+ Revision: 1804697
- Mageia 9 Mass Rebuild

* Wed Feb 12 2020 umeabot <umeabot> 0.80.0-9.mga8
+ Revision: 1495674
- Mageia 8 Mass Rebuild
+ wally <wally>
- replace deprecated %%makeinstall_std

* Wed Sep 19 2018 umeabot <umeabot> 0.80.0-8.mga7
+ Revision: 1269618
- Mageia 7 Mass Rebuild

* Sun Jun 19 2016 pterjan <pterjan> 0.80.0-7.mga6
+ Revision: 1030554
- Rebuild for perl 5.22.2

* Mon Feb 01 2016 umeabot <umeabot> 0.80.0-6.mga6
+ Revision: 929724
- Mageia 6 Mass Rebuild

* Wed Oct 15 2014 umeabot <umeabot> 0.80.0-5.mga5
+ Revision: 747359
- Second Mageia 5 Mass Rebuild

* Tue Sep 16 2014 umeabot <umeabot> 0.80.0-4.mga5
+ Revision: 685560
- Mageia 5 Mass Rebuild

* Fri Oct 18 2013 umeabot <umeabot> 0.80.0-3.mga4
+ Revision: 513180
- Mageia 4 Mass Rebuild

* Sun Jan 13 2013 umeabot <umeabot> 0.80.0-2.mga3
+ Revision: 370256
- Mass Rebuild - https://wiki.mageia.org/en/Feature:Mageia3MassRebuild

* Fri Nov 18 2011 jquelin <jquelin> 0.80.0-1.mga2
+ Revision: 168729
- update to 0.08

* Wed Jan 26 2011 jquelin <jquelin> 0.70.0-1.mga1
+ Revision: 39996
- mageia rebuild
- imported package perl-MooseX-Role-BuildInstanceOf


* Fri Dec 03 2010 Shlomi Fish <shlomif@mandriva.org> 0.70.0-1mdv2011.0
+ Revision: 607003
- import perl-MooseX-Role-BuildInstanceOf