code-controlled module naming conventions?

jae_63 has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: code-controlled module naming conventions? by jethro (Monsignor) on Jul 21, 2009 at 22:53 UTC
You might install Module::Starter and the script module-starter from CPAN (which is a good idea anyway if you write CPAN modules) and just do `module-starter --distro=MassSpec --module=MassSpec::SVGIsotopeClusterGraph --module=MassSpec::ViewSpectrum --module==Lip...` You will then find a directory MassSpec with all modules and other assorted files with skeleton content, exactly fashioned to current practice. Note that you can also select build system and a few other options with module-starter, best read the man page before calling it If you want a direct answer, Search.pm should be in a directory LipcutElementsIO alongside LipcutElementsIO.pm. You might also look at the perl5 libraries in your installation where similar things happen, see Locale and Locale::Country	[reply] [d/l]
Re: code-controlled module naming conventions? by hobbs (Monk) on Jul 22, 2009 at 04:26 UTC
To me, how you keep them in source control depends on how you envision them as distributions. If all of the modules are tightly coupled and you would never want to release one without another, then you would want to have `MassSpec/lib/MassSpec/SVGIsotopeClusterGraph.pm MassSpec/lib/MassSpec/ViewSpectrum.pm MassSpec/lib/LipcutElementsIO.pm MassSpec/lib/LipcutElementsIO/Search.pm MassSpec/t/ MassSpec/Makefile.PL` [download] etc. If you had three separate components that could be maintained and updated separately, then you would treat them as three distributions: `MassSpec-SVGIsotopeClusterGraph/lib/MassSpec/SVGIsotopeclusterGraph.pm MassSpec-SVGIsotopeClusterGraph/t/ MassSpec-SVGIsotopeClusterGraph/Makefile.PL MassSpec-ViewSpectrum/lib/MassSpec/ViewSpectrum.pm MassSpec-ViewSpectrum/t/ MassSpec-ViewSpectrum/Makefile.PL MassSpec-LipcutElements/MassSpec/LipcutElementsIO.pm MassSpec-LipcutElements/MassSpec/LipcutElementsIO/Search.pm MassSpec-LipcutElements/t/ MassSpec-LipcutElements/Makefile.PL` [download] etc. etc. And if all four of them are envisioned as separate components then you might have four dists, but I'm guessing it's not so, and I think I've played with `<code>` enough for now. ;)	[reply] [d/l] [select]
Re^2: code-controlled module naming conventions? by jae_63 (Beadle) on Jul 22, 2009 at 15:43 UTC
Thanks to all for your responses. This one makes sense to me. My context is the "three separate components" scenario described above, as you correctly inferred.	[reply]
Re: code-controlled module naming conventions? by DStaal (Chaplain) on Jul 22, 2009 at 02:08 UTC
For managing them while developing them, do whatever's easiest for you. As a general rule, that's usually the way Perl likes to work. For CPAN, well, perl will read '::' as a directory separator. So making them actual directories is good practice. Note that if you want to distribute them separately, they will want to be in separate directory trees, each under a 'lib' directory in it's own package. So the quite often the normal way to work with these would be to have something like this: `MassSpec-LipcutElementsIO lib MassSpec LipcutElementsIO.pm MassSpec-LipcutElementsIO-Search lib MassSpec LipcutElementsIO Search.pm` [download] (Other expected directories and files omitted for clarity.) So, that's actually an argument for both. (Which is how I develop.) When you want to upload to CPAN, you basically tar up the top-level directories above. (Although there are tools that will help make sure you are getting all the little details right.)	[reply] [d/l]
Re^2: code-controlled module naming conventions? by Bloodnok (Vicar) on Jul 22, 2009 at 14:41 UTC
...you basically tar up the top-level directories... - or `make tardist` in the top level directory of each module. A user level that continues to overstate my experience :-))	[reply] [d/l]
Re: code-controlled module naming conventions? by ELISHEVA (Prior) on Jul 22, 2009 at 06:07 UTC
perlmodlib (see section on "Guidelines-for-Module-Creation") recommends that each component of a module name should have no more than 11 characters and the first 8 of these must be unique from any other module. For the sake of systems that use case-insensitive file names, uniqueness should be distinct letters and not rely on case. Also, each name component should also begin with a capital letter. By convention, names beginning with lowercase letters are reserved for pragmas. It is also often good practice to choose a name for your modules that are consistent with the CPAN naming conventions. You can get a feel for those by typing in topic related key words and module name components into the CPAN search box. You may not want to release anything on CPAN now, but the habit of taking CPAN naming conventions into account will give you more options for the future. Best, beth	[reply]
Re: code-controlled module naming conventions? by Marshall (Canon) on Jul 22, 2009 at 01:45 UTC
I am also curious about this. My model is for example: "use Tk;". That "uses" Tk::Ballon, Tk::Frame and a bunch of stuff via autoloader. Go look at your Perl directory and look at the sub-dirs. Try this: C:\ls perl ..which on my system prints... `bin cpan eg etc html lib man site` [download] If MassSpec is a correctly installed module, then it will work.	[reply] [d/l]
Re: code-controlled module naming conventions? by MadraghRua (Vicar) on Jul 22, 2009 at 16:54 UTC
You might have a look over at the bioperl bulleting boards. There is a very active discussion on refactoring bioperl using Moose as the newer development framework. Given that you are working with mass spec data, there is obvious overlap in how use/call your modules and what the openbio crews typically do. I think being compatible with the module handling conventions in bioperl would help adoption of your modules once you release them into the main stream. MadraghRua yet another biologist hacking perl....	[reply]