Closed rurban closed 8 years ago
My concern with this and #106 is that we intentionally decided not to support all backends and I don't see any reason to change that decision.
This modules has to work or module installation can break. The history of JSON/YAML serializer forward compatibility is poor, so changing backends is a user-specific choice to remove the safeties and risk losing fingers.
I'm not opposed to having xt or maybe TODO tests for other backends, but I wouldn't want this module to fail to install because some backend outside the control of p5p/toolchain suddenly goes and breaks something.
TODO tests that test all the backends under the sun would be fine (and then we would have maximal cpantesters coverage), but agreed, we cannot block installation if something goes wrong outside of this distribution.
It really would be great if the JSON backend could use Cpanel::JSON::XS if available though -- it is vastly faster than JSON::PP. (presently it is only switching to JSON.pm, which has a broken fallback mechanism and only uses JSON::XS/JSON::PP inside.)
See ticket #80
The latest trial releases of Parse::CPAN::Meta may resolve some of the issues in this PR.
Reini, on reflection, I don't think it's a good idea to apply this PR as is. I suggest breaking it up into individual PRs, addressing different issues. To the extent you want to skip/todo tests, please use regular Test::More conventions to do so. All alternate back-ends should be marked TODO.
I suggest you wait on anything about backends until we address #80, which is what I'll be looking at addressing next here at the tail end of YAPC. :-)
Enhance the documentation for JSON and YAML backends.
Add tests for some cperl builtin prereqs.
t/validator.t now tests all installed YAML and JSON backends.
Skip one fixable testfile for which YAML and YAML::XS do not agree. See https://github.com/ingydotnet/yaml-libyaml-pm/issues/44 and https://github.com/Perl-Toolchain-Gang/CPAN-Meta/issues/106