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
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/>
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]:
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 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.)
>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
---------------------------------------------------
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
---------------------------------------------------
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.
@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.
Cheers, Nadim.