FAQ
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)

Search Discussions

  • Ricardo Signes at Oct 9, 2009 at 12:16 pm
    * David Golden [2009-10-09T07:45:22]
    07. Enhance granularity of prerequisites
    Agreed. Also suggest (08. Extensibly Group Prereqs) as related and useful.

    --
    rjbs
  • Graham Barr at Oct 9, 2009 at 1:33 pm

    On Oct 9, 2009, at 7:16 AM, Ricardo Signes wrote:

    * David Golden [2009-10-09T07:45:22]
    07. Enhance granularity of prerequisites
    Agreed. Also suggest (08. Extensibly Group Prereqs) as related and
    useful.
    +1

    Graham.
  • David E. Wheeler at Oct 9, 2009 at 5:26 pm
    On Oct 9, 2009, at 6:33 AM, Graham Barr wrote:
    On Oct 9, 2009, at 7:16 AM, Ricardo Signes wrote:

    * David Golden [2009-10-09T07:45:22]
    07. Enhance granularity of prerequisites
    Agreed. Also suggest (08. Extensibly Group Prereqs) as related and
    useful.
    +1
    +1

    D
  • David Golden at Oct 9, 2009 at 1:57 pm

    On Fri, Oct 9, 2009 at 8:16 AM, Ricardo Signes wrote:
    * David Golden [2009-10-09T07:45:22]
    07. Enhance granularity of prerequisites
    Agreed.  Also suggest (08. Extensibly Group Prereqs) as related and useful.
    Agree on both points.
  • Steffen Mueller at Oct 9, 2009 at 2:11 pm

    David Golden wrote:
    07. Enhance granularity of prerequisites
    +1 in conjunction with proposal 08.

    Steffen
  • Zefram at Oct 10, 2009 at 8:36 pm

    David Golden wrote:
    * Should we go all the way towards making prerequisites phase-specific and
    have "configure_requires", "build_requires", "test_requires", and
    "runtime_requires"
    Yes please. Currently I put things required for testing into
    build_requires, but I feel bad about doing it, because testing really is
    a distinct job from building. Consumers of META information should be
    expected to merge phase-specific requirements in whatever way is suitable
    for their workflow; we can't reliably predict what that workflow will be.

    -zefram
  • Damyan Ivanov at Oct 13, 2009 at 6:17 am
    -=| David Golden, Fri, Oct 09, 2009 at 07:45:22AM -0400 |=-
    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.

    [...]

    * 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)
    Speaking as part of the group that dedicates its time on packaging
    CPAN dists for Debian, I'd say that we don't make difference between
    'building' and 'testing' as the later is always part of the former in
    the Debian package build.

    Separating the requirements for tests that aren't supposed to be run
    during normal package building would be useful. Something like
    "author_test_requires".

    In general, we try to run as much tests as possible, unles they are
    things like Critic tests, which can break with nre releases of
    Perl-Critic.

    Currently we try to fine-tune using environment variables, and this
    works as long as authors use them consistently. Having a separate
    dependency declaration for fargile tests may hopefuly help standartize
    the usage of environment variables to turn them on.

    --
    dam
  • Chris Weyl at Oct 13, 2009 at 8:19 pm

    On Mon, Oct 12, 2009 at 11:17 PM, Damyan Ivanov wrote:
    -=| David Golden, Fri, Oct 09, 2009 at 07:45:22AM -0400 |=-
    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.

    [...]

    * 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)
    Speaking as part of the group that dedicates its time on packaging
    CPAN dists for Debian, I'd say that we don't make difference between
    'building' and 'testing' as the later is always part of the former in
    the Debian package build.
    With RPMs, we don't currently have a mechanisim to differentiate
    between build and test requires, either. However, the distinction is
    a valuable one, I think... We're currently looking at ways to enable
    running tests post-build/install, for QA purposes... This would help
    in that matter.

    I can also see situations where the set of test requirements isn't a
    superset of the build requirements; that is, we might need something
    to build but not to test.

    I guess another way to put it would be "is test just a part of the
    build process, or is test a process of its own?"
    Separating the requirements for tests that aren't supposed to be run
    during normal package building would be useful. Something like
    "author_test_requires".

    In general, we try to run as much tests as possible, unles they are
    things like Critic tests, which can break with nre releases of
    Perl-Critic.

    Currently we try to fine-tune using environment variables, and this
    works as long as authors use them consistently. Having a separate
    dependency declaration for fargile tests may hopefuly help standartize
    the usage of environment variables to turn them on.
    That's essentially our policy in Fedora, too -- any tests not
    explicitly marked as author tests, that test the functionality of the
    code rather than subjective quality (kwalitee, critic, etc) must be
    run. (e.g. Test::Pod tests must be run, but running
    Test:::Pod::Coverage tests isn't mandatory) I don't believe author
    test requirements should be included in any test_requires, as my
    understanding of a test_requires is something the user will require to
    run tests. I can't think of any package including author test
    requirements in test_requires, so I think it's safe to say that's the
    common understanding of the existing spec tag.

    Author tests either skipped unless $ENV{TEST_AUTHOR} or segregated out
    (e.g. in xt/ rather than t/) shouldn't be in test_requires. An
    author_test_requires may help keep authors in sync for situations
    where one dist is maintained by multiple authors (Moose, Catalyst, etc
    come to mind)... But the question of if that's in scope for this
    effort is one best answered by someone else.

    One key I would like to see added would be something along the lines
    of "optional_test_requires" or "test_recommends", etc. There are
    many, many packages that skip tests if some other non-related module
    isn't already installed (e.g. DBIx::Class and
    DateTime::Format::MySQL). It would be _very_ useful to know what
    additional modules are needed to enable so-called optional tests of
    this nature... As per policy we're almost certainly going to have to
    BR them for the build, having ready metadata to assist with this will
    save human cycles.

    -Chris

    --
    Chris Weyl
    Ex astris, scientia
  • David Golden at Oct 13, 2009 at 8:40 pm

    On Tue, Oct 13, 2009 at 4:19 PM, Chris Weyl wrote:
    I can also see situations where the set of test requirements isn't a
    superset of the build requirements; that is, we might need something
    to build but not to test.

    I guess another way to put it would be "is test just a part of the
    build process, or is test a process of its own?"
    It's complicated. In Makefile.PL, with just PREREQ_PM, *all* such
    prerequisites are satisfied after the Makefile.PL is run -- before
    "make" or "make test" -- and all prerequisites are installed if an
    installation is requested.

    With Build.PL, with separate "requires" and "build_requires", both
    sets of prerequisites are satisfied after Build.PL -- before "Build"
    and "Build test" -- but while "requires" are installed,
    "build_requires" may or may not be, depending on settings in
    CPAN/PLUS.

    The argument I've heard for "test_requires" is that someone might want
    to install test_requires so they can run tests after installation, but
    that build_requires would not be needed post installation. I'm not
    sure if that's a real case we should consider or not.
    Separating the requirements for tests that aren't supposed to be run
    during normal package building would be useful. Something like
    "author_test_requires".
    Some have argued for a "release_requires" or "developer_requires" --
    things that an author would want installed during packaging, but that
    wouldn't be needed by end users.
    One key I would like to see added would be something along the lines
    of "optional_test_requires" or "test_recommends", etc.  There are
    If we move to a two-level scheme, we could have something like this:

    prereq => {
    runtime => {
    requires => {
    JSON => 2.00,
    },
    recommends => {
    JSON::XS => 0,
    },
    },
    build => {
    requires => {
    ExtUtils::CBuilder => 0,
    },
    },
    test => {
    recommends => {
    Test::Deep => 0,
    },
    },
    };

    In practice, there may never really be "test/requires", but it would be
    theoretically possible.

    -- David
  • Damyan Ivanov at Oct 14, 2009 at 6:24 am
    -=| Chris Weyl, Tue, Oct 13, 2009 at 01:19:00PM -0700 |=-
    On Mon, Oct 12, 2009 at 11:17 PM, Damyan Ivanov wrote:
    Speaking as part of the group that dedicates its time on packaging
    CPAN dists for Debian, I'd say that we don't make difference between
    'building' and 'testing' as the later is always part of the former in
    the Debian package build.
    With RPMs, we don't currently have a mechanisim to differentiate
    between build and test requires, either. However, the distinction is
    a valuable one, I think... We're currently looking at ways to enable
    running tests post-build/install, for QA purposes... This would help
    in that matter.

    I can also see situations where the set of test requirements isn't a
    superset of the build requirements; that is, we might need something
    to build but not to test.

    I guess another way to put it would be "is test just a part of the
    build process, or is test a process of its own?"
    Agreed. Sorry for making my comments sound like I am against
    separation.
    One key I would like to see added would be something along the lines
    of "optional_test_requires" or "test_recommends", etc. There are
    many, many packages that skip tests if some other non-related module
    isn't already installed (e.g. DBIx::Class and
    DateTime::Format::MySQL). It would be _very_ useful to know what
    additional modules are needed to enable so-called optional tests of
    this nature... As per policy we're almost certainly going to have to
    BR them for the build, having ready metadata to assist with this will
    save human cycles.
    Agreed. We use to watch the build log and add build-dependencies.
    Having some machine-aid to this would certainly be helpful.

    --
    dam

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedOct 9, '09 at 11:45a
activeOct 14, '09 at 6:24a
posts11
users8
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase