Prompted by Convincing Module::Install to put stuff in inc/, here is a description of my toolchain for maintaining my Perl modules (many of which are available on CPAN and on Bitbucket, but some of which are not).
I'm not suggesting that this is the way everybody should maintain Perl code, but it's what works for me.
I have a script called mkdist which creates a skeleton distribution consisting of:
I will then (usually) create a corresponding repository on Bitbucket using my mkrepo script...
#!/usr/bin/perl use 5.010; use strict; use constant BITBUCKET_USERNAME => 'tobyink'; use constant BITBUCKET_PASSWORD => 'my secret'; use Cwd; use Path::Class qw/dir/; use String::Escape qw/printable/; use URI::Escape qw/uri_escape/; sub default_name { [dir(cwd)->dir_list]->[-1] } sub new_bitbucket { my %options = @_; $options{name} //= default_name(); $options{scm} //= 'hg'; $options{has_wiki} //= 'True'; my $body = join '&', map { sprintf('%s=%s', uri_escape($_), uri_es +cape($options{$_})) } sort keys %options; my $cmd = sprintf("curl -S -s -X POST -u %s:%s '%s' -d '%s'", BITBUCKET_USERNAME, BITBUCKET_PASSWORD, 'https://api.bitbucket.org/1.0/repositories/', printable($body), ); my $res = `$cmd`; say $res; return $options{name}; } sub hg_init { system 'hg init'; } sub hgrc { open my $fh, '>', '.hg/hgrc'; say $fh '[paths]'; say $fh 'default = ssh://hg@bitbucket.org/', BITBUCKET_USERNAME, ' +/', shift; } hg_init(); hgrc( new_bitbucket() );
I use Mercurial for version control.
I use Ingy's Module::Package framework which is basically just a wrapper around Module::Install.
What's so cool about it? First and foremost, if you're using Module::Install, the use of plugins can make it tricky for another developer to join in. Your Makefile.PL might have something in it like:
assertos qw(Linux FreeBSD Cygwin);
... and then anyone wishing to check out your development copy and run the Makefile.PL will get a cryptic error message about the assertos function being undefined, and have to use a process of divining to track it down to Module::Install::AssertOS which needs installing separately.
With Module::Package this is avoided. If they have Module::Package::RDF installed, all is well; if not they get an error message saying they must install it, and it automatically pulls in all the Module::Install plugins as dependencies.
The other good thing is that it reduces my Makefile.PL to a single line.
My particular Module::Package set-up is Module::Package::RDF, which comes bundled with the mkdist script I mentioned earlier.
In my meta/ directory I maintain metadata in Turtle format. I'm a big proponent of Semantic Web technologies, so I'd want to produce this metadata anyway, but it does have some practical uses. I use the metadata to output:
In future, I hope to also output a few other files based on this, such as a TODO file.
For general maintenance, I use:
When I need to bump the version number I use perl-reversion.
To build the tarball I use a shell alias perl-makeall which is defined as:
perl Makefile.PL && \ make all test dist && \ make clean && \ rm Makefile.old
And, assuming the release is bound for CPAN (which not all of them are) then another shell alias perl-publish will install it onto my local system, publish it to CPAN, move it to my archive and remind me to tag the release in my version control:
cpanm !^ && \ cpan-upload !^ && \ mv !^ ~/perl5/published/ && \ echo "Do not forget to hg tag the release."
There are various CPAN uploaders on CPAN, but I use Neil Bowers' one which is sadly only on BackPAN these days.
Updates:
Update Aug 2012: shortly after writing the above I switched to installing releases on a perlbrew installation of Perl; thus in the perl-publish shell alias, sudo cpanm !^ has become cpanm !^.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: My Perl Module Toolchain
by Corion (Patriarch) on May 27, 2012 at 20:36 UTC | |
by Tux (Canon) on May 28, 2012 at 09:50 UTC |