Please don't use ::Tiny unless it meets the ::Tiny criteria, thanks!
Don’t get me wrong, I really, really, really appreciate effort put into making something as small and efficient as possible.
However, it seems like we have a recent trend of using ::Tiny for things that do not meet the actual criteria of ::Tiny.
That is bad because seeing ::Tiny gives a certain expectation that, when not met, could be surprising, even bad.
Just because it is way less bloaty than something, like say, Moose: still not necessarily “::Tiny”.
Here are the rules Adam Kennedy originally defined for what ::Tiny means:
- The module should be implemented in "as little code as possible"
- The module should implement a useful subset of functionality
- The module should use at least 1/10th the amount of memory overhead, ideally less than 100k
- The module MUST have no non-core dependencies
- The module MUST be only one single .pm file
- The module should be back-compatible to at least 5.004
- The module should omit functionality rather than implement it incorrectly.
- If applicable, the module should be compatible with the larger module.
If you have a module with ::Tiny in the name space then please either make it ::Tiny or rename it.
Thanks!
/rant
I ♥ perl
Hi Dan, I think that's a fair thing to say.
But I feel in your vibrations :-P that you have particular modules in mind... Maybe you should name them so that the rest of us can take care when using them.
Not sure how practical the suggestion to rename those modules would be. I would have thought that the 5.004 requirement would rule out anything that uses warnings, for a start. That's Routes::Tiny, Role::Tiny, Try::Tiny and HTTP::Tiny out of the picture already. The single-module rule also covers Role::Tiny, Type::Tiny... lots of useful modules, and it seems that renaming those or removing features to comply with that list of rules would cause significant disruption.
Where are these ::Tiny rules documented? Can't see any reference to them from perlmodlib.
okay, just spotted the link to http://beta.nntp.perl.org/group/perl.datetime/2007/01/msg6584.html from XML::Tiny, in the "beware of the leopard" section.
Even the original modules don't comply with those rules any more though - Config::Tiny is 5.8+, unless it's rewriting the code on installation.
5.4 is an absurd requirement for any module, whether Tiny or not.
Perhaps we can bump it up, maybe Adam will agree? still the principle of being able to be used in old perls is really great!
Exactly! Its being used willy nilly without regard for what it specifically means to be ::Tiny.
For example, if I am doing a module that meets some of the criteria but not all, I wouldn’t call it ::Tiny, I’d call it what it is.
> Not sure how practical the suggestion to rename those modules would be.
There was a nice talk about not being afraid to rename a module if its name doesn’t fit anymore, so it isn’t as taboo or difficult as it might first appear.
> Where are these ::Tiny rules documented?
Glad you found them. I also put them in Acme::Tiny in 2008.
Thanks, I don’t want to call anyone out, I just want to try to increase awareness and promote some consistency and best practice.
you're not the cpan police
Maybe make a Dist::Zilla plugin to test for it all?
I doubt many people creating ::Tiny modules would be using the monstrous beast that is Dist::Zilla to manage them.
Answering for Type::Tiny, although the distribution which it is part of is certainly not as tiny as it started out as, the Type::Tiny module itself is still pretty lean. The module itself has no non-core dependencies, and I've even tried to reduce the number of core dependencies as much as possible. (For example, it defines several constants, yet avoids loading constant.pm.)
Several of the other modules in the distribution have one non-core dependency - Exporter::Tiny. Exporter::Tiny started out bundled with Type::Tiny but because it was generically useful ended up being split out.
Type::Tiny and Exporter::Tiny each support perl 5.6.1 and above. I'd love to add support for earlier versions of perl, but these days with modern C compilers it's actually pretty tricky to get archaic versions of perl to build. If I can't get these versions of perl running locally, offering any level of support for them is impractical. Adam's suggestion of supporting perl 5.004 might have made sense at the time he made it, but nowadays is much harder to do. Supporting perl 5.6.2 is a much more achievable line in the sand, especially because it was the first version of perl to bundle Test::More.
At the QA Hackathon in 2013, the Lancaster Consensus was created, which is a collection of standards and practices agreed by toolchain and QA/Test module writers. It stated that the minimum supported Perl going forward would be 5.8.1.
Adam's post was written in 2007, and if you look at perlhist, 5.004 was released in 1997. I.e. it was setting the bar at a Perl that was 10 years old. Perl 5.8.1 was released in September 2003, so it's nearly 11 years old. 5.6.1 was released in 2001, and 5.6.2 in November 2003 (yes, after 5.8.1).
So either 5.6.2 or 5.8.1 seem fine as targets.
Given that the first and only rule of CPAN Club is "there are no rules, as long as you can upload it", at best these are goals / guidelines for aspiring ::Tiny writers ("the spirit of the game").
I also think Tiny can be relative to the module it's a tiny version of — Dist::Zilla::Tiny might just pull in quarter of CPAN rather than half of CPAN, for example :-)
> Maybe make a Dist::Zilla plugin to test for it all?
https://metacpan.org/pod/Dist::Zilla::Plugin::OnlyCorePrereqs can check for one part of it. [Test::MinimumVersion] can test for another.