03 4 / 2012
Over the weekend I travelled to Paris, France for the wonderful Perl QA Hackathon 2012.
This is my second trip to Paris - the last time was around 2007 when I stayed at echolet’s place for Act Hacking, sponsored by the YAPC::Asia funds.
Paris is a great place to visit. Beautiful city, Great food, Subway stations for every 1 minute walk.
The things that bugged me during this travel was the lack of decent 3G prepaid plans for travelers (I wasted 2 days looking for a mobile phone/carrier shop that sells a prepaid SIM card with data, no avail) and hay-fever-like allergy that causes me drowsy eyes and sneezing all the time. Next time, I’ll make sure to find the exact place that sells 3G SIM for travelers and with handful of Claritin capsules.
CPAN testers for cpanminus
On day 1 and 2 I suffered from the hay fever described above, but had a good conversation with garu on his attempt to implement CPAN testers report on top of cpanm’s build.log output. xdg’s blog post mentions this in details.
—test-only for cpanminus
I also implemented —test-only option for cpanminus which ticket was originally created 2 years ago. I was just reminded of the issue by charsbar, and discussed it briefly on irc and gave it a quick run to implement it. This is one of the nicest things about Hackathon - lots of tuits given by just talking to fellow hackers.
--test-only actually installs dependencies if they are not installed. If you want to test a distribution with a fresh non-core dependency versions, you should combine it with
TEST_REQUIRES for MakeMaker
One of thing that I always wanted to implement was to skip
test requires dependencies when
--notest is specified. It felt kind of odd to implement features to skip installing test modules at a “QA Hackathon”, but well, who cares :)
rjbs’s post explains this in details, but overall, my cpanminus code handles the logic to skip test dependencies when
--notest is in effect already, but because majority of build tools, i.e. MakeMaker and Module::Install merge test requires into build requires, the code has never worked like I hoped, in real world distributions.
rjbs took my complaint over our walk back to the hotel on day 2 and he implemented the patch to accept
TEST_REQUIRES, as well as preserving test requires in
META.json when dumping them into
Masaki Nakagawa, while absent from the hackthon, has implemented a pull request for
carton bundle command a few months ago, and now it got merged. Now you can run
carton bundle command to fetch the tarballs from CPAN mirrors and have 02packages file locally, which you can use to replay in the remote machine without relying on external CPAN mirrors on the deployment time. It’s a huge win.
cpanfile is to CPAN what gemfile is to Rubygems. It allows you to describe dependencies for your Perl applications in a DSL pretty close to (and somewhat compatible to) Module::Install or Module::Build::Functions DSL.
First, Perl distributions usually have
Build.PL to describe dependencies and the way to build, test and install dependencies. There’s nothing wrong with these files for CPAN distributions. Meanwhile, when your perl application (even if it is not a CPAN distribution per se) needs a way to describe dependencies when you expect other developers to run it locally cloned from github, or PaaS (Heroku, dotCloud, Stackato) to satisfy its requirements before running on the platform.
Most PaaS providers described above support
cpanm --installdeps . to install dependencies, which means you should put
Build.PL in the repository to push out to these platforms, but to me it always has felt like a non-ideal situation for several reasons:
- What you’re writing is an app, not a CPAN distribution.
- Your application is not meant to be installed. Rather, meant to be run from the current directory
- Experienced developers usually use tools like dzil or Module::Install to list dependencies, and you don’t commit
inc/or generated files to git - which most PaaS uses to deploy files. Ugh.
Dzil has a releaser plugin to cope with this issue, and you can always write
Makefile.PL with MakeMaker by hand, but there’s a gap to this problem.
Self-executing or Perl DSL
Second, these *.PL files are meant to be self-executed, i.e. you run it like a black box
perl Makefile.PL; make; make install. In a recent batch of evolution in CPAN clients and ecosystem such as local::lib, I think it’s a better design for CPAN clients to figure out the way to extract dependencies and how to build & install the application. MYMETA spec and Leont’s CPAN static installer spec is a great way to achieve this, and you can consider
cpanfile as an additional simplification to have a canonical syntax to represent the dependencies in a CPAN::Meta::Prereqs compatible format (in fact, CPAN::cpanfile module only has one method that generates the CPAN::Meta::Prereqs out of the
cpanfile in cpanminus
I added a cpanfile support in cpanminus devel branch, which means you can just have
cpanfile in your application root and expect
cpanm --installdeps . to install dependencies, without having a
Makefile.PL at all. It is a good start, and I’ll expect more support for
cpanfile in the ecosystem such as Module::Install.
Actually, rjbs has just jumped on the wagon a few minutes before I left the venue and implemented cpanfile releaser plugin for dzil.
I hope I can get more done in a coming Carton hackthon in Tokyo next week. I just scheduled this hackathon to work with hackers like Masaki and Tokuhirom, and can also work on features to fill up my slides for OSDC.TW in the weekend right after that. CDD++ :)
I want to give huge thanks to elbeho, BooK and French Perl Mongers for organizing the hackathon, and awesome sponsors who made the hackathon possible.
I heard the QA hackathon will continue going on at London in 2013, and can’t wait to participate to hack more.
Check out my flickr set for more photos taken in Paris.
Permalink 2 notes