This will sound silly, but it only recently dawned on me that a code library isn't just for finished, polished code. It can also be for code that are works in progress that may not be pretty and far from perfect, but is still useful in helping you get actual work done. This summarizes a basic recipe for setting up a "working" library of modules and my workflow for developing these modules.

But first, what exactly do I mean by a "working" library? It's a library for utilitarian modules that you have written to help you in your day-to-day coding or work. The modules are not polished enough or are too specific to release as a formal distribution to CPAN. But they still need tests to make sure they work. For example, I have a collection of modules I use to help me set up and configure WordPress sites on my local machine in Docker. Since these are for my own use, I don't bother setting up a git repo for these module or track issues with them or version them. I just write a test, update the module to pass the test, and then make use of the module right away. Except for comments, I don't bother documenting the modules and most of them are simple enough where the documentation isn't really needed. The goal is to keep the admin overhead of these modules to a minimum while still ensuring the modules work well enough.

So here's what I did to set up my working library:

1. Created a new directory for my modules. I have it set to ~/perl5/working_modules
2. Added this path to the $PERL5LIB environment variable
3. Added my modules to this directory
4. Added a test directory to working_modules for holding tests ~/perl5/working_modules/t. But this directory can be anywhere on your hard drive. It doesn't not have to be in working_modules.
5. Placed any tests into the t directory. I organized the tests using the same structure as my modules in the working_module directory. So a module called Some::Module, has tests in the working_modules/t/Some/Module/ directory

The workflow is simple test driven development: First, write a test in the appropriate test file for the module you are going to add a new feature to and then write the code and run the test. Then get right back to work. I no longer have to worry about whether my tests are including the right path to my modules. Since all my modules are in the $PERL5LIB, I don't have that headache anymore. Before using a working library, I had modules spread out all over my hard drive for different projects I was working on making things very difficult and my code not very reusable or easy to find. Now I just throw a use statement into the code and I'm done.

This obviously isn't anything groundbreaking or new. But if you're anything like me, it took a while before it dawns on you that useful, utilitarian code can dispense with a lot of formalities and you don't have to wait for it to be perfect or even good before you put it into a library.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.