On Oct 8, 2006, at 10:59 PM, Adam Kennedy wrote:
The only downside of this approach is that it requires a CPAN
module for every external system. This is probably quite reasonable
for the top 20 cases and for complicated cases (such as "do I have
a C/XS/etc compiler") but might not be ideal for universal
application to all external dependencies.
Such an approach would have the side-effect of encouraging wrapper
modules, which is always good. Of course, it would be nice if the
wrapper modules themselves could declare *their* dependencies on
external tools... and if that's too easy to do, we're not really
encouraging wrapper modules anymore...
I think there's some overlap here with a conceptual method Audrey
and I were discussing to create a universal cross-language
dependency grammer, which boiled down to a method to specify a
single dependency in an abstract way.
As an early example of this based on a hybrid of PITA testing
context names and the Perl 6 library grammar, a Perl 5 module might
be perl5:Some::Module, a java library might be java:Some.Module, a
dependency on the cvs command would be bin:cvs, and some arbitrary
C headers might be c-h:libfoo.h. This is a very quick and dirty
syntax, and coming up with the grammar/syntax is half the problem.
The idea was to provide a simple platform-specific dependency list
that (after running Makefile.PL) could be passed off so something
like a Debian package resolver, which could then automatically
determine non-Perl dependencies for that module and make sure they
were available with minimal human intervention required to package
some CPAN module.
But this is a conversation for another time and another place (like
the Perl 6 lists or a major multi-language/os conference).
In the short term though, and for special cases, I agree that the
Alien stuff seems the way to go for important cases.
I like the URL-based approach, or namespace-based, or whatever you
want to call it. Keep me (or better, the list) in the loop if this
comes to fruition in some form.
The trick would be to find a way to be forward-compatible gracefully
for tools like M::B, of course...
-Ken
