Bug #112568 for Tree-DAG_Node: should not depend on Test::Pod

On 2016-03-01 13:40:33, ron@savage.net.au wrote:
> Test::Pod is used in xt/authors/pod.t, so it's there for me.
>

Is xt/* run during installation time for end users?

Because if not, then it seems that xt/* would be better characterised as "part of the development phase".

And development-phase-only dependencies have no place in the install time dependency graph.

On 2016-03-01 14:00:57, ron@savage.net.au wrote:
> Hi Kent

>
> It is already, in my mind. Is there some view you're looking at? If
> so,
> please advise. I just went to MetaCPAN and tried clicking on the
> Dependency Graph link on the lower far right, but nothing happened.
>


https://metacpan.org/source/RSAVAGE/Tree-DAG_Node-1.28/META.json#L45

It is no longer in "Runtime requires", sure, but it is still in "Test requires"

Test requires is a child of "the install phase"

Where this dependency should be in $prereqs->{develop}->{requires}, not $prereqs->{test}->{requires}

Because xt/* may be tests, but they're not "install time tests".

They're "develop time tests"

So you presently have "Required for development" dependencies inside "Required to test and install"

On 2016-03-01 14:19:33, ron@savage.net.au wrote:
> Hi Kent
>
> I see, although I no longer get the line #s. I tried various tricks
> earlier by selecting Source/Browse raw/not, but nothing displayed
> them.
> Sigh.

Line numbers sadly require JavaScript enabled to render.

>
> > It is no longer in "Runtime requires", sure, but it is still in "Test
> > requires"
> >
> > Test requires is a child of "the install phase"
> >
> > Where this dependency should be in $prereqs->{develop}->{requires},
> > not
> > $prereqs->{test}->{requires}
>
> I take it you're referring to this para under META_MERGE:
> "
> Where prereqs are concerned, if META_MERGE is used, prerequisites are
> merged with their counterpart WriteMakefile() argument (PREREQ_PM is
> merged into {prereqs}{runtime}{requires}, BUILD_REQUIRES into
> {prereqs}{build}{requires}, CONFIGURE_REQUIRES into
> {prereqs}{configure}{requires}, and TEST_REQUIRES into
> {prereqs}{test}{requires}). When prereqs are specified with META_ADD,
> the only prerequisites added to the file come from the metadata, not
> WriteMakefile() arguments.
> "
> Since there is no such thing AFAICT as
> "$prereqs->{develop}->{requires}", I assume you're referring to
> {prereqs}{build}{requires}.
>
> Now, this is progress! It means I can transfer Test::Pod from
> TEST_REQUIRES to BUILD_REQUIRES, right?

Noooo!

BUILD_ is *worse* than TEST_

The point is Test::Pod should *not* be in PREREQ_PM, TEST_REQUIRES, CONFIGURE_REQUIRES or BUILD_REQUIRES.

All those phases *require* Test::Pod to be installed by the end user in order to test and build the dist.

"Development" requirements are /outside/ the standard ExtUtils::MakeMaker dependency phases, because ExtUtils::MakeMaker should not be worrying about development dependencies at install time.

The only right way to add development-only requirements using ExtUtils::MakeMaker is with custom code generating the "META_MERGE" key.

BUILD_REQUIRES however is worse than TEST_REQUIRES, and is an unfortunate historical blight, because before TEST_REQUIRES existed, people
used BUILD_REQUIRES for the same purpose.

BUILD_REQUIRES is subsequently defined as follows:
- After CONFIGURE_REQUIRES, so you don't need to satisfy them **before** running Makefile.PL
- Required for *ALL* installers, whether or not they're going to run tests (!!!!)

Subsequently, "BUILD_REQUIRES" should be used for things that Makefile.PL doesn't need,  but are otherwise required to do:

`make && make install`

You do NOT want this in 99% of cases.