[rancid] Re: Why doesn't rancid use perl modules?

[Lance Vermilion]

Ed,

I would be willing to help with what I can. I am not by any means an advanced
or for that matter probably even considered intermediate programmer. I pretty 
much hack my way through things to get them to work how I want them. Simple 
things for regular perl coders may take them 10 mins, takes me like 3-4 hours.

As an example. I wanted a slightly different result that is considered part of 
the RANCID-CONTENT-TYPE, so I wrote it today and a script to convert the files
over. What I here took about 4 hours to get it to work and make sure it worked 
on all my Cisco equipment. :(

Have not done any coding with Expect.pm but I did hear it was limited. I am not 
sure how much truth there is to that.

But if the project is willing to move in that direction I will provide what ever
coding I can provide.

-- 

-Lance <rancid at gheek.net>

On Mon, Sep 25, 2006 at 08:45:36PM -0400, Ed Ravin wrote:
> On Mon, Sep 25, 2006 at 04:41:00PM -0700, Lance Vermilion wrote:
> > Hey All,
> > 
> > I was just looking at some things and doing some changes. I
> > noticed there are no perl modules used for things that are used in
> > all the perl scripts. Is there a reason for this? If there is no
> > reason for this I would like to propose moving to perl modules so
> > that the code used in each perl script is less and changes can be
> > made to one module and it would apply to all scripts that reference
> > that module.
> 
> Do you have the time to help do the work?  I think the biggest problem
> with RANCID development at the moment is not the lack of ideas, but the
> lack of developers.
> 
> I'd also like to work on modularizing clogin - ideally, we would end
> up with one rancid script, one clogin script, and a bunch of configuration
> files that defined the differences for 90% of the devices and a few
> extra code modules for the other 10%.  The new clogin and rancid would
> be totally driven by a config file - a few parameters like prompts,
> timeouts, autoenable, etc., and pointers to code modules for weird
> devices that need custom hacking.
> 
> Then we'd have to test it all and make sure it still works :-).
> 
> I think the hardest part is coming up with a good "skeleton" that 
> would become the new framework for all the scripts.  Ideally, the
> framework would be optimized for easy customization, and it would
> be straightforward to convert existing perl and expect scripts
> into the new framework.
> 
> Currently, the only part of RANCID that is "easy" to customize is
> cloginrc.  I'm not fond of the format, but it works.  I've already
> written a Perl module that parses cloginrc (by calling expect on it),
> so a cloginrc-formatted could be used to customize both Perl and
> Expect scripts.  My first instinct is to reach for something broader
> and start from scratch, but that risks hitting the second-system
> effect - it's much more important to modularize RANCID, the config
> file can always be improved later.
> 
> 	-- Ed