John Peacock wrote: >> Is this a problem? If the user doesn't specify a version of a module, >> what >> would version::Limit do? Or do you want to force the user to require a >> version? Ick. > > Well, yes, to use version::Limit correctly, the consumer is *required* > to specify a version that they are requesting, since otherwise, Perl's > 'use' never calls the UNIVERSAL::VERSION routine, and hence > version::Limit never gains control to enforce the author's strictures.
Ahh. I would be of the opinion that if the user really doesn't care what version they get they shouldn't have to make something up. > No, I don't like that limitation, but I also don't see any way around it > (apart from overloading the CORE::use method, which to be honest, I > haven't tried). Why don't you just use import()? > However, in this case I wasn't suggesting that version::Limit be the > actual solution to your requested improvement to META.yml (sorry if it > seemed like I was). I was only suggesting it as one way to consider how > to give the module author a means of providing a firm set of API > guarantees, above and beyond Perl's rather limiting "give me any version > of the requested module above some lower limit." Indeed, if META.yml > included the kind of Scope argument that version::Limit employs: > >> "[0.0.0,1.0.0)" => "constructor syntax has changed", >> "[2.2.4,2.3.1)" => "frobniz method croaks without second argument", > > The module author could be very specific about which releases of > dependencies it was tested/compatible with, as well as provide a compact > notation of its own API guarantees. There would be an optional stanza > to each "requires" key that had a scope stanza, as well as an option > "provides" stanza that had the scope for this module. I'm hoping to be able to avoid worrying about that level of detail for now as I think it's well within the 20 part of the 80/20 rule (the last 20% that takes 80% of the time). -- package Outer::Space; use Test::More tests => 9;
