Ken Williams wrote:
>
> On Nov 20, 2007, at 7:24 PM, Michael G Schwern wrote:
>
>> Syntax-wise, I'd rather see something like this:
>>
>> requires:
>> external:
>> svn: 1.4.2
>> mysql: 5.0
>> python: 2.1
>>
>> That way there is no ambiguity about whether a given requires key is a
>> module
>> name or something special. Module names have simple values, special
>> keys have
>> complex values. Then there is no name clash.
>
> There's no compelling reason to link "modules" with "simple" and "other
> stuff" with "complex". Let's decouple them or I think we'll be sorry.
Huffman encoding. We're much more likely to depend on a pile of CPAN modules
and, if any, a handful of external utilities. It also nicely separates the
two, visually. Finally, it does away with lots of prefixes.
> When I've been mulling this issue over on my long boring commutes,
> here's the best proposal I've come up with for prerequisites of
> different types: explicit type declarations.
>
> requires:
> mod/Carp: 1.03
> mod/File::Basename: 2.73
> sys/perl: 5.005
> sys/platform: Windows
> bin/wget: 1.10
> bin/gpg: 1.4.5
> lib/tk: 8.4
> lib/cups: 2
> ext/mysql: 5.0
> ext/openssl: 0.9.71
*snip*
> The main advantage of this approach, I think, is that if an existing
> parser sees something it can't figure out the meaning of (or how to
> satisfy), it will fail. Which is important for something called a
> "requirement".
Yes, that's a nice feature. The "external" as its own key with a non-scalar
value should satisfy this as well.
$ perl Makefile.PL
Warning: prerequisite external HASH(0x1801180) not found.
> The idea is similar to the protocol at the front of a URI (and I think
> the role-reversal of slashes and colons is sort of cute, e.g.
> mod/Foo::Bar::Baz, but we could make the slash almost any character we
> want).
I don't agree that we need a second tier of categorization. Why is perl in
sys and not bin? Why is mysql in ext? Why is openssl not in lib? These are
questions we don't need to answer if we split everything up into "perl
modules" and "everything else".
The only reason I can think of for categorizing them is to attempt to have
some sort of unified mechanism for dependency resolution. As there is no
unified way to determine the version number, or even if its installed, of
"everything else" there's really no reason to try to categorize them.
OTOH having external types does at least allow us to take a guess without
having to encode every single possible external dep up front.
--
Life is like a sewer - what you get out of it depends on what you put into it.
- Tom Lehrer
