# from Adam Kennedy # on Friday 29 February 2008 00:31: >> http://scratchcomputing.com/svn/CPDK/trunk > >We've all got the same thing... > >I just call mine ADAMK::Starter, ADAMK::Release and don't put them on >the CPAN :)
http://scratchcomputing.com/svn/CPDK/trunk/bin/publish_module http://scratchcomputing.com/svn/CPDK/trunk/demos/trial01/.perl_developer.yml That's not my own config, but it is close. Pretty much everything under 'publish' gets regular exercise. It would have more tests if I could figure out how to setup a simulated pause server without it needing a vm. (See recent, unanswered, mldistwhat mail.) The starter parts are still very punted. >The approach we probably need here is something plugin-based... so >that individual actions can be added, removed, configured, maintained, >etc. The config file is designed to have support for plugins. Yet to be written -- but a "get this method from this package" sort of thing triggering a require and [some hand-waving]. Maybe as simple as adding a 'require' key, but I haven't decided yet in what ways that would break (I have only a dark inkling that it will.) I would like to hear some feedback on what is missing from the code or docs from the point of view of an active author besides myself. That would give me enough confidence in the API/config stability and flexibility to ship it. Then, if you even need them, I'll do the plugin loader and you can create plugins until the kangaroos come home. I did go as far as getting all of the actions and settings to be defined only in the config file and have used the project-directory override feature config file on a couple of dists. But I already decided that "plugins" is not the way to configure and/or add/remove actions. Well, maybe with more sophisticated class composition, but definitely not with straight subclasses. But even if they're made of moose and traits and roles and/or bolts you still go nuts debugging the configuration. Note the leading dot scheme -- the '.test' step under 'process' just means to call `Build (or make) test`. So that's a whole realm of customizable and user-definable actions which don't even need a plugin. You can define ACTION_my_dist_thingy in your build class, then just put '.my_dist_thingy' in the sequence and run it. >A toolkit approach is quite possibly not welcome in this problem > domain. It doesn't have to be a toolkit, it just needs to be configurable in the same place for all of the needs throughout the lifecycle and must not require a subclass to e.g. set a constant. So, somewhat more toolkitish than a rusty collection of bent screwdrivers and a hammer handle in a burlap bag, but stopping far short of a shiny "hello kitty" chest packed with matching wrenches, sockets, screwdrivers, and etc. --Eric -- "Because understanding simplicity is complicated." --Eric Raymond --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
