view release on metacpan or  search on metacpan

lib/Acme/CreatingCPANModules.pm  view on Meta::CPAN

[slide] OK, relax :-)

C<Module::Starter> has a bunch of options you can use, but the most
important three ones are these: --module for the module name, --author
for the author's name (you) and --email for the author's email address
(it's always good to allow users to contact you).

[slide] So let's exemplify this (we'll do this in the slides and then
we'll move on to a terminal and try all this again).

[slide] I'm going to create the module C<Acme::CreatingCPANModules>,
[slide] with the author "Jose Castro" (that's me, in case you didn't
notice... my name is also in the bottom right corner of the slides...
:-) ) [slide] and my email address: cog at cpan dot org.

[slide] There. Module created!

No, it doesn't do anything yet, but it already exists!

[slide] So let's see what happened and exactly what was created.

With the `tree` command [If your system doesn't provide the `tree`
command tool you can try installing C<Filesys::Tree>]!

[slide] OK, then...

OK, let's go through this step by step...

Here on the bottom we have a t/ directory, which is the directory
where you put your test files (it's a convention). Inside it are a few
.t files (that's also a convention for test files). We'll get to these
in a while.

You'll also notice the .pm file. That's your module!

Everybody knows what a README is, but we'll also get to that.

The Makefile.PL is what's going to be used to install your module, and
MANIFEST contains the list of files the distribution includes... don't
try to think to hard about all this, we'll get to all this in a
moment.

And then there's the Changes file, where you're supposed to write down
the changes you made to your module each new version.

Let's look at the files in detail.

[slide] Here's a Changes file.

Note that the order of the changes is chronologically inversed. Why?
Because the purporse of a changes file is (among others) to let the
user know what you changed from the last version, so that he can
decide if he wants to install your module.

Hence, and since browsers and editors usually open files in their
beginning, it's only reasonable that you put the most recent changes
on the top of the file.

As for what you put in here, it's kind of up to you, but you don't
need to be too technical. If you added some tests, just say "added
some tests". You don't really need to specify which ones and the
purpose of each of them.

[slide] Next up we have the MANIFEST. This is the file that lists
everything that goes into your distribution.

Why? Because this way you're able to put more stuff in the directory
and not have the final step of creating the distribution include those
files.

If you're thinking "why would I put things in that directory if they
weren't part of the distribution", think, for instance, in a test file
that only runs in your machine.

One of my modules has tests with two files that take almost 200M each.
I don't think the users wouldn't want to download a 400M distribution
when they can do with a 20K one.

Hence, those files of mine are in that directory but not listed in the
MANIFEST.

The drawback on this is that whenever you add a file to the
distribution you have to remember to update the MANIFEST.

[slide] Next up, we have Makefile.PL

Now, you really don't need to understand what's in here, but it's
still quite self-explanatory.

There's the name of the of the distribution, the author, etc. Do note
the C<PREREQ_PM> parameter. If your distribution requires another
module to be installed, that's where you defined that. Just add the
name of the module to that hash and put the minimum version number of
the module that you require.

[slide] Next we have the README. What you put in the README is, once
again, up to you. I always put the same documentation from the main
module, some people just put a template README in all their
distributions.

Whatever you do, don't forget to update the README at least once, as
it's the file many users look at and the default documentation can be
kind of... embarassing ;-)

[slide] And now we finally have our module!

The module is comprised of two things: code and documentation.

Both are equally important.

I can't stress how much.

Whether you put your documentation at the beginning or at the end of
the file, or perhaps entwined with the code, is, again, up to you.

We're not staying for a long time at this slide because we'll have the
time to do so in the demo, right after this.

[slide] And now we're at the first test file.

Currently, through C<Test::More>, it checks to see if the module loads
correctly. It also diagnoses what it's doing.

[slide] Then we have another test file, which was recently introduced,
to check if files like README and Changes have content written by you
or are just the default templates.

[slide] The next one is checks if you're documenting all your public
functions. It assumes that if you have a private function (that is, a
function that's not meant for the public but rather to be used by your
other functions) you will name it something commencing with an
underscore.

This means that you need a section with the name of each function that
doesn't begin with an underscore.

[slide] And this one over here ensures that your POD is valid.

[slide] So let's go through it one more time: Changes for the list
of changes, MANIFEST with the list of files, Makefile.PL to be used
for installation, README, your module, and a bunch of tests.

[slide] Very well, then. Time for the live demo!

[I change to the next workspace and we're set] You know what they say
about live demos? They say "Don't!" O:-)

OK, then, first we'll create our module. [I type `module-starter
--module=Acme::CreatingCPANModules --author='Jose Castro'
--email=cog@cpan.org`]

There, done.

Now, the first I'm gonna do is get rid of C<boilerplate.t>. Well, not
really getting rid of it, I'll just put it aside for the time being
and I'll explain you later why I'm doing it. [`cd
Acme-CreatingCPANModules` and `mv t/boilerplate .`]

Now we're set.

Suppose we were installing this module.

The first thing to do it `perl Makefile.PL` [`perl Makefile.PL` and ls
-al]. As you can see, this has created C<Makefile>.

This now allows us to do things like this [`make`]. And now we can
test our distribution [`make test`].

As you can see, all our tests have passed... but that's simply because
we still don't have anything interesting in our module...

Let's add some code. [I add the code for new(), set() and get(), as
follows:

  sub new {
    my $self = shift;
    my $foo = shift;
    bless \$foo, $self;
  }

  sub set {
    my $self = shift;
    my $newfoo = shift;
    defined $newfoo or return undef;
    $$self = $newfoo;
    return $self->get();
  }

  sub get {
    my $self = shift;
    return $$self;
  }

and some documentation for these methods]

Now, let's run the tests again. [`make test`]

OK, so we haven't broken anything yet, good :-)

Now, let's add some more tests [`cp t/00-load.t t/01-basic.t`].

As you can see, [`make test`] running the tests again runs this new file.

Now let's change a few things in this new file of ours. [`vim
t/01-basic.t`, remove the last line and add instead: