Re: RFC and Questions regarding a module to automate and centralize infrastructure administration

[stevieb]

"In general, what are the implications between Foo::Bar and Foo::Baz as opposed to Foo::Bar and Foo::Bar::Baz"

Foo::Bar and Foo::Bar::Baz are within the same second level namespace hierarchy. That means you can have module files under the same directory structure:

Foo-Bar
    |
    /lib
      |
      /Foo
         |
         |--Bar.pm
         |
         /Bar
            |
            |--Baz.pm

The former, you'd be taking up two slots at the top level namespace, which typically isn't desired from the CPAN perspective unless it coincides with other work. Always try to fit what you have into an existing namespace if possible, and try to keep things contained, instead of spreading them out. For instance, what you're trying to do seems like it would fit under the Net:: top level namespace. If that's the case, a consideration would be:

Net::Circumstance::Automate; # main module
Net::Circumstance::Automate::Command;
Net::Circumstance::Automate::DB;
Net::Circumstance::Automate::Config;
Net::Circumstance::Automate::SSH;
Net::Circumstance::Automate::RDP;

Then, in your main module, you could suck in all of the lower modules, and return new objects based on parameters to the constructor call, or have separate methods depending on what needs to be done. The config and db modules could be called early on within a constructor to set things up for any following calls.

The dir structure would look like this:

lib/
   - Circumstance
   |- Automate
   |   |- Command.pm
   |   |- Config.pm
   |   |- DB.pm
   |   |- RDP.pm
   |   |- SSH.pm
   |
   |- Automate.pm

You could also set things up so that you have full-blown inheritance, so that your end-user directly asks for a sub object, and the lower-level items pull in methods and configuration based on its parents, and things may look differently.

When designing something like this that is *bound* to expand exponentially, laying it out in a way that will be extensible is paramount. My suggestion is to start small, use Module::Starter to get set up, muck about, then start your unit tests. While writing tests, you'll quickly find out if your layout and/or your structure makes sense for going forward.

There is no one answer for this, as you are very quickly going to realize. Test, play, scrap, test, play scrap.

The one piece of advice I do have here that my fellow Monks will all agree on, is use a Version Control System (VCS). Github is free, as is Bitbucket. Spending the time to learn git (or hg or svn etc) now will save you enormous amounts of time going forward.

[cbeckley]

Thank you very much. I didn't have much trouble finding the documentation to write my first module, but finding guidelines on how to organize modules in relation to each other has proven more elusive. <cue the flood gates!> And now that I've rolled one by hand, I'll definitely give Module::Starter a try. So, thank you again.

Version Control. Yes. I'm a zealot actually. I've been religiously stuffing my whole life into various VCS's since the days when RCS was an exciting improvement to SCCS. :)
But always good advice, and never over stated.

I do have another question about the integration of my module hierarchy into the greater CPAN tree, but I'll follow up after I've done a little more research and can ask an intelligent question.

Thanks again,
cbeckley