Michael G Schwern wrote:
John Peacock wrote:
The big problem with it is that the consumer of the module must include a
version number on the `use` line for this magic to work. I haven't figured out
a way to require this (due to the vagaries of Perl's `use` code).
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.
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).
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.
John
