My ~/bin is full of scripts, Perl, bash, or whatever else I found suitable for a task at the time. For small Perl scripts, I often don't declare any package; but often (especially when using an OO abstraction) I just put one or more

{   package My::Frobnicator;
    ...
}
[download]

Modulinos were fun, but the right time to prefer them is never. If you need to reuse the code, just create a module. Even if no one else is going to use the module (how could you know?), creating a module is a good thing: it's much easier to test it and reuse it.

I'd love to give you some examples, but the public repository of my scripts doesn't contain much stuff I'm still as proud of as when I created it.

After some experiments with a variety of Getopt modules and other stuff, I eventually got into the habit of using MooseX::App::Cmd, especially for stuff which is "just for myself", and found it to be pretty rewarding in the long run. Here are some of the points I like:

• The command / subcommand makes it easy to setup an environment (modules, configuration) of tasks which are somewhat related. Adding a new subcommand is dead easy: Just write an execute method for a Moose module.
• The command, entered by itself, provides a list of available subcommands. I tend to forget things and find this a lot better than ls -l ~/bin if I had individual scripts for every action.
• I don't write or modify my CLIs often. With MooseX::App::Cmd, parameter validation and documentation for the CLI play nicely with my usual habits for modules, whereas helpers like Getopt::Long and Getopt::Long::Descriptive are really nice but have learning curves of their own.

I'd probably hesitate, though, to use MooseX::App::Cmd for commands which are to be released with a small module or package because of its impressive list of dependencies.

I'm a bit late to the discussion, but here's my general train of thought:

I'm all for code re-use, but just as I don't optimize prematurely, I also don't code for nonexistent future requirements prematurely. So if there is no foreseeable reason to want to re-use the code, I just get on with writing the script. If there is a possible future reason to re-use the code, I'll still just write the script.

Whenever I have a little downtime, I'll go through my ~/bin (which is part of my source code tracked with CVS, and now git, that follows me everywhere), and look for candidates for re-use. I hardly ever find anything, yet I keep adding scripts that I use regularly. When I know something'll get re-used, then I'll break that out into a module.

I don't use any of the App::*-type modules, but that's mainly because I've never found any that were a good fit for me. I'm watching this thread for suggestions, though.

Most of my "personal use" scripts start like this:

use Local::Stuff; # See below

my %o = ( 
    help => sub { pod2usage( -verbose => 2 ) },
    # ... defaults go here ...
);
GetOptions(\%o, qw< help option=s other=i >) or pod2usage();

__END__
=head1 POD Documentation
[download]

What is Local::Stuff?

Local::Stuff is a convenience module I wrote. It stays local to my systems, as the name suggests. It uses Import::Into to hack the caller's namespace to enable pragmas like strict, warnings, and autodie, as well as pull in modules I use frequently and import a few helper subs. All of its features are configurable, but I rarely have to do so. Finally, it's actually spelled Local::Shit to dissuade myself from using it in client code. (Edited to clarify Local::Stuff is not a public dist.)

what are the best, most efficient practices for creating a cool library of perl commands to help you get work done faster?

Use something like Module::Starter to create a skeleton for your new module, then add your cool library code to lib/Local/Cool.pm, write some unit tests in t/, and now you have a module that can be installed easily on anything that runs Perl. See perlnewmod for more info.

As for scripts, you already have the right idea. Just throw them in ~/bin (and use some kind of version control like git).