07. Enhance granularity of prerequisites Proposal:
Add "test_requires" distinct from "build_requires". (Adam Kennedy) This proposal is driven by the needs of the downstream distribution packagers. At Oslo, they requested this separation to allow them to more accurately package modules. I forget, however, the EXACT mechanism that this change was driving downstream, and this MUST be clarified before we add it. Adding a new dependency type simply because it looks like a good idea isn't sufficient, we need to be absolutely sure that it does what the downstream wants before we add it. Comments: * Should we go all the way towards making prerequisites phase-specific and have "configure_requires", "build_requires", "test_requires", and "runtime_requires" (i.e. deprecate the old "requires" entry) (Dagolden) I see no obvious benefit to changing requires -> runtime, just more change, breakages and work ([[User:AdamKennedy|AdamKennedy]]) * Prerequisites are combined in usage during toolchain phases. E.g. "requires" are expected to be available after the configure stage before the build stage. This needs to be clearer in the spec and may have implications for CPAN/CPANPLUS. (Dagolden) * Do distribution packages really need test_requires? I cannot think of a use case. (SlavenRezic) * They generally don't. That's the reason to have it: test_requires would be a list of modules the CPAN version needs for testing, but downstream could filter out. (JosBoumans) * Source Based distros ''can'' use it. The users can elect whether or not to perform test phase. Most chose not to, but for those who want assurance, its handy.(kentnl) * Speaking from a Debian perspective, whether it is required for testing or for building, we include it as a Build dependency. We try to run as many tests as possible (including author tests, though we prefer AUTOMATED_TESTING to RELEASE_TESTING now). We would really consider test_requires and build_requires equivalent. (jawnsy)
