Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Prerequistie for Marpa::HTML

2 views
Skip to first unread message

Jeffrey

unread,
Mar 17, 2010, 10:59:37 PM3/17/10
to module-...@perl.org
I've got a new module out on CPAN (Marpa::HTML). It requires another
new module of mine (Marpa). I'm getting a lot of "NA" or "UNKNOWN"
cpantesters results for Marpa::HTML because of the absense of the
Marpa module at the required version level.

Please note I'm talking about the lastest revs here: Marpa-HTML
0.101_000 and Marpa 0.100000. I've had similar problems with earlier
versions but I've since (at least so I thought) fixed my Module::Build
setup.

I wonder

1.) Is this to be expected when a new module (first non-developer
release) is a prerequisite?

2.) Is my set-up still at fault? META.yml, which is created by
Module::build has a "Marpa: 0.100" line, which I hoped would suffice.

3.) Is this a problem with some of the cpantesters setups.

thanks, jeffrey kegler

Aristotle Pagaltzis

unread,
Mar 18, 2010, 8:23:47 AM3/18/10
to module-...@perl.org
* Jeffrey <jeffre...@jeffreykegler.com> [2010-03-18 13:00]:

> 1.) Is this to be expected when a new module (first
> non-developer release) is a prerequisite?

No.

> 2.) Is my set-up still at fault? META.yml, which is created by
> Module::build has a "Marpa: 0.100" line, which I hoped would
> suffice.

Neither your Makefile.PL nor your Build.PL list Marpa as
a requirement at all. It’s kinda funny that you go to extra
effect to get Module::Build to hack it into the META.yml, by way
of `meta_add`, when just listing the prereqs properly would make
it do that automatically for you. What made you do that?

In any case the result reported by the Testers is entirely to be
expected, and is just what users will experience if they try to
install your module with any CPAN installer: they’ll be forced to
resolve the dependency manually before it will install.

> 3.) Is this a problem with some of the cpantesters setups.

No.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

Jeffrey

unread,
Mar 20, 2010, 11:32:18 PM3/20/10
to module-...@perl.org
@Aristotle: Your two one-syllable answers were very useful. The bug
you spotted in your longer answer was from a previous release.

But armed with the knowledge that the voice of experience indicated
that the problem almost certainly lay in my packaging, I went back and
added the Marpa module to *both* the 'require' and 'build_requires'
for Marpa::HTML. Now all seems to work perfectly.

An obstacle for me was that Module::Build's actual behavior seems to
contradict the documentation in Module::Build::API, which says of
'build_requires' that

"Modules listed in this section are necessary to build and install the
given module, but are not necessary for regular usage of it."

Read literally, that says that any module necessary for regular usage
should never be listed under 'build_requires'. As far as I can tell
the actual behavior of Module::Build would be more in accord with the
following:

"Modules listed in this section are necessary to build and install the
given module. If a listed module is necessary for regular usage as
well as the build and install, the listed module also needs to be
specified using the 'requires' argument."

Thanks, jeffrey

On Mar 18, 5:23 am, pagalt...@gmx.de (Aristotle Pagaltzis) wrote:
> * Jeffrey <jeffreykeg...@jeffreykegler.com> [2010-03-18 13:00]:

sawyer x

unread,
Mar 22, 2010, 3:51:35 AM3/22/10
to Jeffrey, module-...@perl.org
Hi

On Sun, Mar 21, 2010 at 5:32 AM, Jeffrey <jeffre...@jeffreykegler.com> wrote:
As far as I can tell
the actual behavior of Module::Build would be more in accord with the
following:

"Modules listed in this section are necessary to build and install the
given module.  If a listed module is necessary for regular usage as
well as the build and install, the listed module also needs to be
specified using the 'requires' argument."

I see a patch submission rising!
(get it? bad moon rising?)

Anyway, I suggest submitting a documentation patch! :)
 
S.

Aristotle Pagaltzis

unread,
Mar 22, 2010, 5:55:07 AM3/22/10
to module-...@perl.org
* Jeffrey <jeffre...@jeffreykegler.com> [2010-03-22 00:50]:

> @Aristotle: Your two one-syllable answers were very useful.

I realised afterwards that the mail reads somewhat gruff rather
than (as intended) amused. Sorry.

> An obstacle for me was that Module::Build's actual behavior
> seems to contradict the documentation in Module::Build::API,
> which says of 'build_requires' that
>
> "Modules listed in this section are necessary to build and
> install the given module, but are not necessary for regular
> usage of it."
>
> Read literally, that says that any module necessary for regular
> usage should never be listed under 'build_requires'. As far as
> I can tell the actual behavior of Module::Build would be more
> in accord with the following:
>
> "Modules listed in this section are necessary to build and
> install the given module. If a listed module is necessary for
> regular usage as well as the build and install, the listed
> module also needs to be specified using the 'requires'
> argument."

Right, it’s simply that one of these is for code that runs in
normal operation and the other is for the code that runs during
installation. If a module is needed at both times, it should be
listed in both sections.

It’s odd that adding to `build_requires` fixes any problem
though. Older CPAN toolchains only understand `requires`, and
many modules list all their dependencies there and do not even
have a distinct `build_requires` list. To my knowledge those
modules work fine. So your problem is a bit of a mystery. Hmm.

(Nevertheless, your solution is the correct thing to do, so don’t
go reverting it.)

Eric Wilhelm

unread,
Mar 22, 2010, 2:12:30 PM3/22/10
to module-...@perl.org
# from Jeffrey
# on Saturday 20 March 2010 20:32:

>An obstacle for me was that Module::Build's actual behavior seems to
>contradict the documentation in Module::Build::API, which says of
>'build_requires' that
>
>"Modules listed in this section are necessary to build and install the
>given module, but are not necessary for regular usage of it."
>
>Read literally, that says that any module necessary for regular usage
>should never be listed under 'build_requires'.

Yes, they should be listed as 'requires'.

What actually happens is that M::B writes the prerequisites into
_build/prereqs (and MYMETA.yml), then prints some warnings about
whichever ones are missing. After that, it's up to your cpan client.

Modules listed in 'requires' will be present at build time. Modules
in 'build_requires' *may* not be present after installation. I'm not
aware of any reason why it would be useful to list them in both.

Perhaps the meta spec is clearer about this?

http://module-build.sourceforge.net/META-spec.html#build_requires

We welcome documentation patches in the RT queue.

Thanks,
Eric
--
software: a hypothetical exercise which happens to compile.
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------

Eric Wilhelm

unread,
Mar 24, 2010, 2:56:32 PM3/24/10
to module-...@perl.org
# from Jeffrey
# on Saturday 20 March 2010 20:32:

reference: https://rt.cpan.org/Ticket/Display.html?id=55909

>I went back and
>added the Marpa module to *both* the 'require' and 'build_requires'
>for Marpa::HTML.  Now all seems to work perfectly.

But it appears that you changed the rest of the Build.PL code at the
same time, which is actually what fixed the problem.

>An obstacle for me was that Module::Build's actual behavior seems to
>contradict the documentation in Module::Build::API,

What happens on the installation side is actually under the control and
responsibility of the cpan client.

We really need an informational pamphlet explaining the whole "Your cpan
client and Makefile.PL/Build.PL, META.yml, MYMETA.yml,
configure_requires, build_requires, requires" thing, but here's a short
version:

configure_requires: installed before running Build.PL

build_requires: available at ./Build, not required after install

requires: available at ./Build, permanently installed

The client:

1. checks META.yml
1a. satisfies 'configure_requires'
2. runs Build.PL
3. reads MYMETA.yml
3a. satisfies 'build_requires'
3b. satisfies 'requires'
4. runs ./Build && ./Build test && ./Build install
5. installs stuff from 'requires'
6. optionally installs stuff from 'build_requires'
7. optionally installs stuff from 'configure_requires'

Where 'satisfies' often means "download, build, test, and add to
$ENV{PERL5LIB} before continuing", which is where the "optionally" part
in #6 and #7 comes in.


If you're using a module in your Build.PL or build class, you have to
either:

enter it in 'configure_requires'

or

have it in 'build_requires' or 'requires'
and defer loading it until ./Build time.


--Eric
--
Like a lot of people, I was mathematically abused as a child.
--Paul Graham
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------

Jeffrey

unread,
Mar 24, 2010, 2:25:16 PM3/24/10
to module-...@perl.org
I created ticket 55909 in queue 'Module-Build' for this issue. I am
agnostic on whether this is a documentation bug or a
misimplementation.

I eventually put the requirement in both 'requires' and
'build_requires', but that's just because I want to get my module
tested. It does look like, going forward, situations where the same
module is specified in 'requires' and 'build_requires' will need to be
supported. Otherwise folks who thought they needed to specify both
will have their modules stop building.

On Mar 22, 11:12 am, enoba...@gmail.com (Eric Wilhelm) wrote:
> Perhaps the meta spec is clearer about this?

In my reading the meta spec is less clear. The meta spec could be
read as supporting either behavior, while the Module::Build::API is
clearly wrong if the behavior I observed is the intended behavior.

Jeffrey

unread,
Mar 25, 2010, 5:50:50 PM3/25/10
to module-...@perl.org
Btw, this is probably as good an opportunity as any for me to express
my gratitude to those who created Module::Build, as well as those who
make the whole CPAN infra-structure available.

@Eric: Perhaps the very useful "phamphlet" you wrote could be added to
the Module::Build documents. Since its contents aren't specific to
Module::Build, someone might argue that's not the "right" place, but
as a practical matter it's where people will find it.

nadim khemir

unread,
Mar 27, 2010, 6:29:50 AM3/27/10
to module-...@perl.org
pamphlet? did I miss something useful?

Cheers, Nadim.

0 new messages