David Golden wrote:
I don't seem to have is_qv:
$ perl -Mversion -E '$v=version->new(1.2); say $v; say $v->is_qv'
1.2
Can't locate object method "is_qv" via package "version" at -e line 1.
Oops, the xs code doesn't expose that (I was testing with the pure
Perl); I'll fix that (as well a
On Mon, May 18, 2009 at 9:32 AM, John Peacock
wrote:
> The code you committed is actually more complicated than it needs to be:
>
>> === lib/Module/Build/Base.pm
>> ==
>> --- lib/Module/Build/Base.pm (revision 2562)
>> +++ lib/Modu
David Golden wrote:
Fixed in trunk. All versions supplied to requires, build_requires,
configure_requires, etc. are now normalized if they are a version
object or appear to be a dotted tuple.
The code you committed is actually more complicated than it needs to be:
=== lib/Module/Build/Base.p
On Sun, May 17, 2009 at 10:52 AM, Elliot Shank wrote:
> I've got a M::B subclass that forces itself into configure_requires. This
> subclass also uses version.pm. Parse::CPAN::Meta cannot handle the
> resulting META.yml (example attached), which means that current CPANPLUS
> cannot install any d
On Sun, May 17, 2009 at 04:19:36PM -0400, David Golden wrote:
> As for the check -- maybe we just see if Parse::CPAN::Meta can parse
> the resulting file? We just need something to protect authors from
> themselves if they do something custom to META.yml and to get M::B
> bugs reported before a d
On Sun, May 17, 2009 at 9:05 PM, John Peacock
wrote:
> That being said, the last time we fixed this in M::B was to force module
> versions to be stringified; we should do the same here. There aren't
> that many places in M::B where you can specify a version...
More to the point, I would like to
David Golden wrote:
> I don't know that we should attempt to write a general hook when 99%
> of cases to date are version.pm. I think we just need to be smarter
> about the specific places in META.yml that could contain a version
> number.
What I really wish is that classes could register a callb
On Sun, May 17, 2009 at 12:15 PM, Eric Wilhelm
wrote:
> I wonder: Can we put in a general-purpose hook to catch this kind of
> thing, or do we have to just remember it whenever we add another new
> might-be-an-object attribute?
I don't know that we should attempt to write a general hook when 99%
Beyond not-supporting it, the other biggie is that this completely
violates encapsulation.
Worse, since version.pm wasn't involved in the serialisation, any YAML
parser that DID support this would just stuff a HASH full of the data
you see there and blindly bless it into any class it's told. There
# from Elliot Shank
# on Sunday 17 May 2009:
>Adam's response:
>> This is a bug in Module::Build, it forgot to serialize the version
>> object in configure_requires before writing it into the META.yml.
>>
>> Module::Build should probably do this in the general case anyway,
>> objects shouldn't be
10 matches
Mail list logo
