Autrijus likes the fact I've moved to a "chronicles" style for my posts.
While it works really well when your entire life is consumed by a single project which a lot of people find interesting, like Pugs(autrijus), JSAN(cwest) or PPI(yours truly), I don't think it's going to survive well over the long term.
I mean, "Day 1312" is getting just a little crazy don't you think? What do I look like, a daytime soap opera? Wait! I could be the handsome but evil doctor! And people could be afflicted with tiny clusters of tumors! :) But I digress...
I think it makes it harder to talk about other things easily without breaking the pattern. Unless I move to a sort of piped multiple header, or do several journal entries a day (one is more than enough for me).
Today, firstly, I got no changes or bug reports for PPI. I'm taking this as a good thing. I've written to Ovid (my grant dom, er, I mean manager) telling him he can get off my back now and sod off.
It all looks good for the big day tomorrow.
But I also just realised I'll be releasing it on Day 1313 since the first code went into CVS.
Fortunately, I've never really been supersticious, so I hereby dare the universe the do anything to stop the release.
The other thing I wanted to comment on quickly was Test::Inline 2, which has been out now for a while. While it works really well, the more I use it the more I feel the API and console interface came out a bit malformed.
So I'm going to bite the bullet and make some back-compatibility-breaking changes now before it has any more time to get heavy adoption.
I'm adding another Handler class, Test::Inline::Content, for the generation of the test script content. This will mean we can write extentions to make things like Template Toolkit support for script templates relatively sane and easy to do. It's currently way too much work to do some tasks in the script content tweaking department that seem like they should be simple to do.
I'm also rearranging the other handler classes slightly, but the APIs themselves remain unchanged so it should mean changing a few lines of code for anyone working against the API directly and everything will be fine.
I'm also going to change the interface to inline2test to work from a config file instead of only having the ugly and growing list of --options.
Since inline2test isn't really documented now, I'm going to pretend I don't have an obligation to maintain compatibility here (which is a lie) but the config files should make things much more flexible, and mean that people that currently have to custom code something against the API can get the same job done with the config file alone.
I'll be doing the next couple of releases as 2.099_xx devel releases, so people who are affected will have a chance to play before the 2.100 changeover.
Oh, and finally, can anyone tell me how the hell I install a data file in a CPAN module with naming it .pm and pretending it's a module? I want to get JSAN::Indexer working soon, but I have no idea where data files for CPAN modules are supposed to live.
cpan installs that just fine, and I can get at it from my module by mucking around with my entry in %INC. The last bit is ugly though, and I'd like to know how to improve it.lib/My/Module.pm
/Module/my_data_file
It looks and feels like a hack, but it worked for me.my $datafile_path = $INC{'My/Module.pm'};
$datafile_path =~ s!\.pm$!!;
$datafile_path.= '/my_data_file';
