21. Formalize optional_features Proposal:
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 documented. (Tux) Comments: * 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 choice (AdamKennedy). * optional_features may be used automatically. This is already implemented in CPAN.pm in conjunction with the "features" key of distroprefs. (SlavenRezic) * 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)