Re: Version parsing confused by sub version {}
> On Fri, 16 Nov 2007 12:49:44 -0800, Michael G Schwern <[EMAIL PROTECTED]>
> said:
> A bug in MakeMaker's parse_version() was found recently. Module::Build has
> the same bug.
> https://rt.cpan.org/Ticket/Display.html?id=30747
> It's reproducible by getting the version from a module like this:
> $VERSION = 1.23; sub version { $VERSION }
> and then this:
> use version; $VERSION = version->new(2.34);
> The version() routine pollutes the namespace in which the $VERSION code is
> evaled. It thinks version->new() is version()->new() calling the polluting
> version() routine. MakeMaker fixed it by deleting any version() routines
from
> the symbol table before trying to eval the $VERSION code.
A different and slightly less brute fix would probably be to say
version::->new() like I do on all package names always everywhere
because it's the only safe way to call a method on a package name that
has no colons in it.
Have you considered this option?
--
andreas
Re: Adding a perl_version key to META.yml
> On Fri, 16 Nov 2007 09:48:18 -0800, Eric Wilhelm <[EMAIL PROTECTED]> said:
> # from Andreas J. Koenig
> # on Thursday 15 November 2007 23:39:
>> > So I'd like to propose a perl_version: key for META.yml, which
>> would be > specifically to identify the minimum Perl language version
>> dependency of the > module.
>>
>> +1
> +1
>> And then the documentation must be adjusted that has the example
>>
>> requires:
>> ...
>> perl: 5.005_03
> Yes, and the META.yml consumers which supported the old way will need to
> check the spec version and look for a requires => {perl...} if it is
> old spec.
> Build.PL can't change though. (Unless I can think of a way to
> auto-generate a Build.PL for compatibility with stale M::B's.)
> And, running Build.PL should still give the same output, right? (unless
> CPAN.pm is going to self-upgrade.)
Yupp, we need to maintain the old way to express the same thing for
the next 12 years or so.
--
andreas
Re: Version parsing confused by sub version {}
# from Andreas J. Koenig
# on Saturday 17 November 2007 01:54:
>A different and slightly less brute fix would probably be to say
>version::->new() like I do on all package names always everywhere
>because it's the only safe way to call a method on a package name that
>has no colons in it.
Well, or any package whatsoever.
$ perl -e 'use strict; use warnings; sub foo::bar () {"this"};
foo::bar->new'
Can't locate object method "new" via package "this"
--Eric
--
If the above message is encrypted and you have lost your pgp key, please
send a self-addressed, stamped lead box to the address below.
---
http://scratchcomputing.com
---
Re: Version parsing confused by sub version {}
> On Sat, 17 Nov 2007 02:10:40 -0800, Eric Wilhelm <[EMAIL PROTECTED]> said:
> # from Andreas J. Koenig
> # on Saturday 17 November 2007 01:54:
>> A different and slightly less brute fix would probably be to say
>> version::->new() like I do on all package names always everywhere
>> because it's the only safe way to call a method on a package name that
>> has no colons in it.
> Well, or any package whatsoever.
> $ perl -e 'use strict; use warnings; sub foo::bar () {"this"};
> foo::bar->new'
> Can't locate object method "new" via package "this"
Thanks::for::the::correction::)
--
andreas
Re: Version parsing confused by sub version {}
Dear god that is evil.
How the hell is doing that sort of stuff.
Adam K
On 17/11/2007, Michael G Schwern <[EMAIL PROTECTED]> wrote:
>
> A bug in MakeMaker's parse_version() was found recently. Module::Build
> has
> the same bug.
> https://rt.cpan.org/Ticket/Display.html?id=30747
>
> It's reproducible by getting the version from a module like this:
>
> $VERSION = 1.23; sub version { $VERSION }
>
> and then this:
>
> use version; $VERSION = version->new(2.34);
>
> The version() routine pollutes the namespace in which the $VERSION code is
> evaled. It thinks version->new() is version()->new() calling the
> polluting
> version() routine. MakeMaker fixed it by deleting any version() routines
> from
> the symbol table before trying to eval the $VERSION code.
>
> Here's code to reproduce:
>
> $ cat Version_Sub.pm
> package Version_Sub;
>
> $VERSION = 1.23; sub version { $VERSION }
>
> 1;
>
>
> $ cat Uses_version.pm
> package Uses_version.pm;
>
> use version; $VERSION = version->new(2.34);
>
> 1;
>
>
> $ perl -wle 'use aliased "Module::Build::ModuleInfo"; print
> ModuleInfo->new_from_file("Version_Sub.pm")->version; print
> ModuleInfo->new_from_file("Uses_version.pm")->version'
> 1.23
> Can't call method "new" without a package or object reference at (eval 10)
> line 8, line 3.
>
>
> --
> Insulting our readers is part of our business model.
> http://somethingpositive.net/sp07122005.shtml
>
>
Re: Adding a perl_version key to META.yml
On Nov 15, 2007, at 5:38 PM, Adam Kennedy wrote: After a number of incidents, it would appear that putting the Perl version dependency into requires is just too problematic to be an appropriate solution. Why? It also has implications from a CPAN graph perspective. If a module has a Perl language version dependency, we can short- circuit Makefile.PL, and we can even short-circuit configure_requires, because there's simply no point bothering. Sure, but I don't understand why this means we need to turn requires => perl into perl_requires. Consumers can do all the same short- circuiting on requires => perl. -Ken
Re: Adding a perl_version key to META.yml
Ken Williams wrote: > On Nov 15, 2007, at 5:38 PM, Adam Kennedy wrote: > >> After a number of incidents, it would appear that putting the Perl >> version >> dependency into requires is just too problematic to be an appropriate >> solution. > > Why? Because cramming two meanings into one name sucks. It complicates the implementation and invites users to forget the less frequent of the two meanings creating subtle bugs. "requires" and all it's ilk can be described as "the key is a module name and the value is a version number... UNLESS the key is 'perl' in which case the value is the version of perl". If that was a subroutine's documentation I'd tell you to split it into two routines. Let's put it on it's head. We control META.yml. META.yml consumers have to write special code to handle "requires: perl" anyway. What's the advantage of doubling up the meaning of "requires"? It didn't take advantage of any existing code or meaning. Why not make up a new key? -- Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: Makefile.PL 'use 5.005_04' or require?
Ken Williams wrote:
>> What is the reason for saying require? If there is one, we need a begin
>> block, right?
>
> Yeah. I guess it was require() because we wanted to have a nice error
> message even for perl4? That hardly seems like an important use case
> anymore though.
"use 5.xxx" is a 5.6 thing. "require 5.xxx" goes back to at least 5.4.
Given that the whole point is to tell users using older perls that they need a
higher version of perl, it's important in this case to remain backwards
compatible.
BEGIN { require 5.xxx } is ok.
--
I do have a cause though. It's obscenity. I'm for it.
- Tom Lehrer
Re: META.yml author field
David Golden wrote:
> On 10/29/07, Ken Williams <[EMAIL PROTECTED]> wrote:
>> On Oct 28, 2007, at 4:54 PM, Ron Savage wrote:
>>> From my point of view, as a module author, the spec has the bug in it.
>> Yet look what happens to everyone's parsing tools when we change the
>> spec in the name of "convenience":
>> [snip]
>> # Can't use string ("Ron Savage <[EMAIL PROTECTED]>") as an ARRAY ref
>>
>> So I'm starting to reconsider changing it actually.
>
> Before re-engineering the spec for "convenience", remember that this
> whole thread would never have started if Module::Install had just
> implemented the spec the way it was written.
>
> Whose convenience are people thinking about? The few (if any) that
> hand-write their META.yml? As Ken shows, it's not any more
> "convenient" for parsers -- they would have to support things both
> ways.
The important thing here is that there are TWO different things going on here.
1) The representation of authors in the META.yml.
2) How an author tells the META.yml generator who the authors are.
For the former, readers of META.yml, they want it represented in an
unambiguous fashion which does not require them to worry about any special
cases. For the latter, they want it to DWIM.
Fortunately, these contradictory desires are served by two entirely different
interfaces and both can be satisfied.
A META.yml generator is free to allow the user to enter the list of authors
anyway way they like COMPLETELY REGARDLESS of how it's actually represented in
META.yml. For example, in MakeMaker AUTHOR is a single scalar. It then turns
that into a list for the META.yml.
Keep the spec unambiguous. Put the DWIM into the META.yml generator
(MakeMaker, Module::Build, Module::Install... whatever).
--
Whip me, beat me, make my code compatible with VMS!
