On 25/11/2007, Ken Williams <[EMAIL PROTECTED]> 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. > > I agree that there needs to be some way of extending our notion of > prereq types from the 2 current types (module and 'perl'). I > disagree that it should be done in a backwards-incompatible way > though. The cardinal rule of syntax extensions must be kept in mind: > any new functionality must be a syntax/semantics error in the old > system, or else old parsers will continue on their merry way and do > The Wrong Thing.
I'd like to see some URIs that outline the logic behind this "cardinal rule". I'm generally against any solution that starts with "first, break every existing tool", and maintaining backwards compatibility wherever possible has long been one of the principles by which the toolchain has been developed. We've already seen what happens with things like the PREFIX incident. What that means in this context is that if we want old parsers to > ignore new META information, we should put it in a new key. If we > don't, we should incorporate it into existing keys. > > In other words, if we encourage people to change 'requires => perl => > 5.6' to 'perl_requires => 5.6', old parsers will happily ignore the > new key, and miss an important dependency. That's a problem I don't > want anyone, least of all myself, to have to work around. Parsers may miss it, but for the most part that's not a major problem. The primary mechanism for implementing the version dependency is the bailing out from the Makefile.PL/Build/PL. The contents of META.yml is advisory. Also, the omission of the "perl" key from the spec is unfortunate, > but it was always intended to be there, it exists in the wild, and > parts of the toolchain (M::B itself, for example) already support > it. So I would be quite loathe to get rid of it. > > 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 This idea was originally proposed a couple of years ago. The problem was coming up with a naming scheme that extend beyond the Perl toolchain. For example, defining things like Java class dependencies, etc. The problem is creating an identifier system for dependencies is not one I think we should be going it alone on. Adam K
