Beware the devilish lure of writing a ::Simple or ::Lite module. I often hear people say they are writing something "like Template Toolkit, but faster and more lightweight." They eventvually discover that there was a good reason for those features that seemed pointless to them at first, and soon the lightweight module grows into a beast.

That's not really the issue here though. In this case, the issue is that the module which does what you want (Class::Accessor) requires you to inherit from it, and you don't want to.

I have a lot of sympathy for not wanting your namespace polluted. I hate it when people put things in UNIVERSAL:: and I try to be very careful about namespace stuff. However, if I avoided every module I didn't like the interface of, I would be rewriting a ton of code.

Just to name a few, Regexp::Common, CGI, Getopt::Long, Apache::Session and Data::FormValidator all have pretty annoying APIs. (I don't like the much-replicated HTML::Template interface either. Sorry Sam.)

I hold my nose and use these modules because they work, get my job done, and save me tons of time. In your case, writing something to make accessors is so trivial that I suppose you aren't saving that much time, so it could go either way. I don't personally see the interface problems as very serious though.

Regarding your troubles with Bricolage installation, I still think the smartest way to distribute an application that relies on CPAN modules is to bundle them with it, along with a build script that installs them into a local directory. This has worked really well for Krang, and the company I work for has adopted this approach for all of our software. It avoids module versioning issues and allows you to patch a broken module locally if you have to.

There is no need to run the test scripts for every single module when you build them -- just run the tests for Bricolage. If they are not good enough to tell whether you have a working Bricolage system by themselves, improve them.