Last LCA I started hacking on a small RDF research project with the
author of mulgara (google is).
What we were looking at was a way to come up with an RDF schema (most
likely extended one of the existing package meta-data schemas) for
describing language-agnostic interdependencies.
As part of that we looked at what the complete set of required
dependencies might be, reviewing half a dozen languages' source
repositories in the process (Perl, R, Python, Ruby, erlang, I forget the
others).
The full list of dependencies we came up with was
configure_requires
build_requires
test_requires
install_requires
runtime_requires
These dependencies would not necesarily be to classes, it works for Perl
because the index lets us resolve a class to the current package
containing it.
Mapping these values to CPAN, runtime_requires becomes "requires" and
build_requires, test_requires and install_requires were all capable of
being folded into the one "build_requires".
configure_requires was the problem in CPAN, because it couldn't be
turing-complete, and hence the proposal to add this to META.yml to
complete the full set of functionality.
I guess what I'm saying is that build, test, and install all have
basically the same properties. The can be evaluated at configure-time,
and are turing-complete (i.e. code).
So for the purposes of a working installer for users, there is no
distinction between the three and they can be folded in together.
Now, for more advanced stuff, like testing/retesting, these can be
distinct. But for legacy reasons, we currently only have build_requires,
and I didn't want to engage in proposing both
test_requires/install_requires and configure_requires at the same time,
since it potentially confuses the issue, and configure_requires is the
most important thing we needed.
Adam K
Eric Wilhelm wrote:
Had there been a discussion of something like this?
I think META.yml should have test_requires, and possibly also
test_recommends.
Particularly, since we have ACTION_retest(), we should ensure that
everything is available.
--Eric
