21. Formalize optional_features
Optional features: is supported in META.yml, but it requires a lot of
manual intervention and trickery to make it work. And it is very poorly
* Not all YAML parsers parse that structure the same way, so the order of
this section inside META.yml is vital (still :()
* I for one would be happy to see optional_features: removed entirely,
since actual actions resulting from this information only apply in the
human-in-the-loop cases. It also locks downstream packagers into either
supporting it or not supporting it, none of THEIR users actually get a
* optional_features may be used automatically. This is already implemented
in CPAN.pm in conjunction with the "features" key of distroprefs.
* optional_features can be however quite practical to people with source
based distributions as long as they're done properly. Gentoo tends to
match each optional_feature to a corresponding 'use' flag. ( Set it and
forget it ). (kentnl)
* The example of optional_features express a optional 'feature' as having
'requires' prerequisites as an 'alternative' to specifying 'recommends'.
But what would 'build_requires' within an 'optional_features' entry mean?
Is 'recommends' allowed within 'optional_features'? What should
CPAN(PLUS) do for each of the prerequisite types if found under an
optional_feature entry? (Dagolden)