That doesn't fix the problem of abandoned branches, but it does at least cut down on some of the noise.
]]>Thus the claim that Test modules would have to be written specifically against Test2, in order to be able to work with other Test2-based modules, is simply factually incorrect.
That wasn't what I was trying to claim. Maybe I don't understand what you and Leon wanted to happen.
My point was simply that Test2-using tools will not cooperate with code that uses the existing pre-Test2 Test::Builder. Of course, if Test::Builder is using Test2 under the hood, then tools using Test::Builder do not also have to change (but AFAICT no one is saying they should).
]]>For the end-users, a split is clearly the less risky option, and there doesn't seem to be any direct advantage to them in keeping the ecosystems unified.
I think the advantage for end users is that they can use things that test module authors produce. For example, with the TeamCity formatter I referenced in my earlier comment, it is nearly impossible to make a better version in the current ecosystem. Parsing TAP is incredibly painful, because TAP sucks (I need to write a blog post on this) and simply doesn't have enough information in it.
With Test2, I can create a much less buggy, much more useful TeamCity formatter. This will directly benefit anyone who wants to use existing test tools like Test::More under TeamCity.
This logic applies to many other testing tools that will benefit from Test2. Being able to write more reliable, more flexible, better tested test tools with less work is a win for everyone who wants to use those tools.
]]>I work on two test modules that will greatly benefit from Test2. These are Test::Class::Moose (TCM) and TAP::Formatter::TeamCity (TeamCity).
Neither of these modules would see much (if any) benefit from an opt-in approach.
When using TCM, you need to use other test modules like Test::More, Test::Fatal, etc. to actually do any testing. TCM is essentially a harness, but it doesn't provide the low-level "is this the expected value" type testing pieces.
For TCM to work with Test2, every single module you use to output tests must also use Test2. This means that a TCM built on top of Test2 would only be useful to people who were willing to write their entire test suite with other modules that had opted into Test2.
This would be viable for green field code bases that could choose to use Test2::Suite (which is pretty damn great), but presumably most existing TCM users are using Test::More and friends.
So to use Test2 in TCM (which has allowed me to _hugely_ improve the internals and fix many bugs with parallel testing), I'd either have to make a new distro (T2CM?) or tell everyone using TCM that the next release will break their entire test suite. Neither of these options seem very appealing, though I suppose the new T2CM distro is a better bad option. That said, I don't really want to maintain two separate distros!
The TeamCity formatter is in a similar situation. Unless the entirety of a test suite is emitting T2 events, I cannot write a decent TeamCity formatter. At $WORK, where we use this formatter, we already have a huge test suite built on top of TCM, Test::More, etc. We are really not likely to rewrite it all to use Test2::Suite any time soon (though I hope to at least use it for _new_ code going forward).
So that leaves us back with the two options that mst brought up. Do nothing or merge it and see what happens (with the option of unmerging in the face of catastrophe). T2 brings many huge improvements for test module authors. It's a huge step forward for the Perl testing ecosystem. I think the benefits it offers are worth some risk.
has _request => (
is => 'ro',
isa => 'Catalyst::Request',
init_arg => 'request',
predicate => '_has_request',
);
]]>
'yMMMD'
, I believe.]]>
DateTime->format_cldr()
and get the format from $locale->format_for('y')
and ->format_for('yM')
that should do the trick.So you never plan to write code that presents information to the user in their local time zone? Really?
I think good timezone support is pretty crucial to most applications that have to interact with users outside of a single office.
]]>Other than that, I think grant applications for this sort of software are fine. I think the big question will be whether this is software that other people use. I don't think it's a good use of TPF's money to fund speculative projects or projects with very few users.
]]>The Perl blogs site makes a poor bug reporting tool.
]]>