[perl #70866] use/package with "numeric literal" VERSIONs
Frank Wiegand
# Please include the string: [perl #70866]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=70866 >
This is a bug report for perl from frank....@gmail.com,
generated with the help of perlbug 1.39 running under perl 5.11.2.
-----------------------------------------------------------------
This topic has already been partially mentioned, see
http://www.nntp.perl.org/group/perl.perl5.porters/2009/10/msg151830.html
perldoc5.11.2 -f package about »package NAME VERSION« syntax:
»VERSION must be be a numeric literal or v-string».
perldoc5.11.2 -f use:
»VERSION may be either a numeric argument such as 5.006, which
will be compared to $], or a literal of the form v5.6.1«
perldoc5.11.2 about these I<numeric literals>:
Numeric literals are specified in any of the following floating
point or integer formats:
12345
12345.67
.23E-10 # a very small number
3.14_15_92 # a very important number
4_294_967_296 # underscore for legibility
0xff # hex
0xdead_beef # more hex
0377 # octal (only numbers, begins with 0)
0b011011 # binary
Those are all the things which pass C<looks_like_number>, so why is
C<looks_like_number> not used when perl parses C<package> and C<use>
statements?
So I consider C<package> and C<use> are broken:
% cat Foo.pm
package Foo .1;
1;
% perl5.11.2 -c Foo.pm
syntax error at Foo.pm line 1, near "package Foo .1"
Foo.pm had compilation errors.
% cat Foo2.pm
package Foo2;
our $VERSION = 1;
1;
% perl5.11.2 -e 'use Foo2 10'
Foo2 version 10 required--this is only version 1 at -e line 2.
BEGIN failed--compilation aborted at -e line 2.
% perl5.11.2 -e 'use Foo2 1e1' # same as above but no failure
The last one parses wrong:
% perl5.11.2 -MO=Deparse -e 'use Foo2 1e1'
use Foo2 (10);
-e syntax OK
Thanks, Frank
-----------------------------------------------------------------
---
Flags:
category=core
severity=low
---
Site configuration information for perl 5.11.2:
Configured by fw at Fri Nov 20 12:50:33 CET 2009.
Summary of my perl5 (revision 5 version 11 subversion 2) configuration:
Platform:
osname=linux, osvers=2.6.30-2-amd64, archname=x86_64-linux
uname='linux hal2 2.6.30-2-amd64 #1 smp fri sep 25 22:16:56 utc 2009 x86_64 gnulinux '
config_args='-de -Dusedevel -Dprefix=/opt/perl/perl-5.11.2'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.3.4', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64
libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=/lib/libc-2.10.1.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.10.1'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'
Locally applied patches:
---
@INC for perl 5.11.2:
/opt/perl/perl-5.11.2/lib/site_perl/5.11.2/x86_64-linux
/opt/perl/perl-5.11.2/lib/site_perl/5.11.2
/opt/perl/perl-5.11.2/lib/5.11.2/x86_64-linux
/opt/perl/perl-5.11.2/lib/5.11.2
.
---
Environment for perl 5.11.2:
HOME=/home/fw
LANG=de_DE.UTF-8
LANGUAGE=
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/sbin:/usr/sbin:/home/fw/bin:/home/fw/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
PERL_AUTOINSTALL=--defaultdeps
PERL_BADLANG (unset)
PERL_EXTUTILS_AUTOINSTALL=--defaultdeps
PERL_MM_USE_DEFAULT=1
SHELL=/bin/zsh
David Golden via RT
numbers in Perl [1], I'd much rather see the rules tightened rather than
loosened.
I agree that the current docs do not describe reality well, but I'd much
rather see the documentation amended than to loosen what is allowed to
looks_like_number.
I'd rather go even further and really restrict allowable version number
forms, but I haven't the energy and tuits to roll that rock uphill
against "breaks backwards compatibility" naysayers.
But if I had my way, there would be only two allowed forms:
(1) decimal: limited to positive decimal numbers matching qr/\d+(?:\.\d+)?/
(2) dotted-integer: only with a leading v and at least three components,
with no component other than the first greater than 999; matching
qr/v\d+(?:\.\d\d?\d?){2}(?:\.\d\d?\d?)*/
My regexes are probably buggy given the hour, but hopefully people get
the idea. I'd like to remove any possible ambiguity between forms. I'd
like to see "alpha" underscores go away. I hate how much time I've
spent dealing with version number issues while working on the Perl
toolchain.
-- David
[1] http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/
Andreas J. Koenig
> I'd rather go even further and really restrict allowable version number
> forms, but I haven't the energy and tuits to roll that rock uphill
> against "breaks backwards compatibility" naysayers.
Since the syntax 'package Package Version;' is a new syntax we are
absolutely free to design this one right from scratch, no?
It reminds me of Larry's choice of C< (? > in regular expressions that
opened a whole new world of possibilities without breaking backwards
compatibility.
--
andreas
Steffen Mueller via RT
On Fri Nov 27 20:26:52 2009, dago...@cpan.org wrote:
> Having thought long and hard about the insanity of module version
> numbers in Perl [1], I'd much rather see the rules tightened rather than
> loosened.
It seems hard to disagree with that.
> I agree that the current docs do not describe reality well, but I'd much
> rather see the documentation amended than to loosen what is allowed to
> looks_like_number.
>
> I'd rather go even further and really restrict allowable version number
> forms, but I haven't the energy and tuits to roll that rock uphill
> against "breaks backwards compatibility" naysayers.
I think this fear is addressed well by Andreas' comment: You can't break
backwards compatibility in new syntax (unless the syntax itself possibly
breaks compatibility, cf. class keyword). You can only break
expectations. And I think that's precisely what you (and I and many
others) *want* here.
> But if I had my way, there would be only two allowed forms:
>
> (1) decimal: limited to positive decimal numbers matching
qr/\d+(?:\.\d+)?/
>
> (2) dotted-integer: only with a leading v and at least three components,
> with no component other than the first greater than 999; matching
> qr/v\d+(?:\.\d\d?\d?){2}(?:\.\d\d?\d?)*/
>
> My regexes are probably buggy given the hour, but hopefully people get
> the idea. I'd like to remove any possible ambiguity between forms.
Those regexes seem fine to me.
> I'd like to see "alpha" underscores go away. I hate how much
> time I've spent dealing with version number issues while working
> on the Perl toolchain.
At first, I went *yuck*. Don't take away my tools to mark something as
alpha. But then, I realized that I want to mark distributions as alpha,
not packages/modules. So it doesn't apply unless I insist to only ever
use the version from a .pm file in a distribution version. I don't.
IMHO, a decision on the behaviour and subsequent documentation fixes
should be considered a 5.12 showstopper or else we lose the window of
opportunity to define new syntax with the sane behaviour.
Note that if we realize limiting the valid versions specifiers in the
construct was a bad idea, we can relax it later. Just not the other way
around.
Cheers,
Steffen
Jesse
> At first, I went *yuck*.
Ditto, but I've come around, thanks mostly to well-reasoned explanations
by several porters. I see the value in making the new syntax
only accept version numbers of the two styles mentioned by David.
> IMHO, a decision on the behaviour and subsequent documentation fixes
> should be considered a 5.12 showstopper or else we lose the window of
> opportunity to define new syntax with the sane behaviour.
Let's do it. I've marked this ticket as a 5.12 showstopper. We can
always loosen it up for 5.14.
-Jesse
John Peacock
> Ditto, but I've come around, thanks mostly to well-reasoned explanations
> by several porters. I see the value in making the new syntax
> only accept version numbers of the two styles mentioned by David.
I'm +1 on this as well, and if there is anything that needs to get
changed in the version code to make this easier, I will make time to
change it.
John
Zefram
>But if I had my way, there would be only two allowed forms:
>
>(1) decimal: limited to positive decimal numbers matching qr/\d+(?:\.\d+)?/
>
>(2) dotted-integer: only with a leading v and at least three components,
>with no component other than the first greater than 999; matching
>qr/v\d+(?:\.\d\d?\d?){2}(?:\.\d\d?\d?)*/
We ought to put accurate regexps into the documentation, both to directly
document the syntax and for people to copy into toolchain modules.
I think the regexps you actually want are
qr/(?:0|[1-9][0-9]*)(?:\.[0-9]+)?/
qr/v(?:0|[1-9][0-9]*)(?:\.(?:0|[1-9][0-9]{0,2})){2,}/
This rules out non-ASCII digits, octal literals, and v-string components
that look like they might be octal (though they actually get interpreted
as decimal anyway). Alternatively, if you want to support v-string usage
such as "v2010.02.28" (for dates), the latter restriction can be dropped,
leading to
qr/v[0-9]+(?:\.0*(?:0|[1-9][0-9]{0,2})){2,}/
which would also allow "v2010.0002.0028", which you might not be
intending. If you actually want a restriction on the *number of digits*
in later v-string components, rather than on the numerical value, you get
qr/v[0-9]+(?:\.[0-9]{1,3}){2,}/
I hate v-strings.
Also, when you add anchors to these regexps, be sure to use /\A/ and
/\z/, not /^/ and /$/, because we don't want newlines creeping into
version numbers either.
-zefram
Frank Wiegand
> We ought to put accurate regexps into the documentation, both to directly
> document the syntax and for people to copy into toolchain modules.
That would be great. The hints for setting version numbers using a (new)
»best practise« should be at least mentioned in `perldoc -f package' and
perlmodstyle.pod, IMHO.
> I think the regexps you actually want are
>
> qr/(?:0|[1-9][0-9]*)(?:\.[0-9]+)?/
[...]
> If you actually want a restriction on the *number of digits*
> in later v-string components, rather than on the numerical value, you get
>
> qr/v[0-9]+(?:\.[0-9]{1,3}){2,}/
Using these REs, here are some ticket candidates from CPAN:
% cat bad-versions.pl
#!/usr/bin/perl -w
use 5.010;
use strict;
my $valid = qr/\A (?: (?:0|[1-9][0-9]*)(?:\.[0-9]+)? ) | (?: v[0-9]+(?:\.[0-9]{1,3}){2,} ) \z/x;
while(<>) {
chomp;
my ($module, $version, $dist) = split;
next if $version eq 'undef';
say if $version !~ /$valid/;
}
__END__
% zcat 02packages.details.txt.gz | tail -n+10 - | perl bad-versions.pl
Apache::mod_pml VERSION P/PJ/PJONES/PML-0.4.1.tar.gz
Array::Parallel .01 W/WI/WILL/Array-Sort-0.02.tar.gz
Array::Suffix .5 B/BT/BTMCINNES/Array-Suffix-0.5.tar.gz
Business::Payroll::US::FedIncome .3 J/JA/JAMESP/payroll/business-payroll-1.3.tar.gz
Business::Payroll::US::FICA .4 J/JA/JAMESP/payroll/business-payroll-1.3.tar.gz
Business::Payroll::US::Medicare .4 J/JA/JAMESP/payroll/business-payroll-1.3.tar.gz
Business::Payroll::US::Mileage .3 J/JA/JAMESP/payroll/business-payroll-1.3.tar.gz
Database::Schema::Config .02 S/SA/SAXJAZMAN/database/Database-Schema-Config-.02.tar.gz
DBIx::Class::Fixtures::SchemaVersioned set-when-loading L/LS/LSAUNDERS/DBIx-Class-Fixtures-1.001001.tar.gz
DBR unknown I/IM/IMPIOUS/DBR-1.0.7rc2.tar.gz
Device::Gsm::Charset Revision C/CO/COSIMO/Device-Gsm-1.54.tar.gz
EC::About v36 R/RK/RKIES/ec-1.28.tar.gz
EC::PasswordDialog v36 R/RK/RKIES/ec-1.28.tar.gz
HTML::Encapsulate v0.3 N/NP/NPW/HTML-Encapsulate-v0.3.tar.gz
IO::Stty .02 A/AU/AUSCHUTZ/IO-Stty-.02.tar.gz
JListbox .01 D/DJ/DJBERG/Tk-JListbox-0.01.tar.gz
LWP::UserAgent::Snapshot v0.2 N/NP/NPW/LWP-UserAgent-Snapshot-v0.2.tar.gz
Mail::SpamAssassin::Conf bogus J/JM/JMASON/Mail-SpamAssassin-3.2.5.tar.gz
Mail::SpamAssassin::Dns bogus J/JM/JMASON/Mail-SpamAssassin-3.2.5.tar.gz
Mail::SpamAssassin::Plugin bogus F/FE/FELICITY/Mail-SpamAssassin-3.1.8.tar.gz
Mail::SpamAssassin::PluginHandler bogus F/FE/FELICITY/Mail-SpamAssassin-3.1.8.tar.gz
Mail::SpamAssassin::Reporter bogus J/JM/JMASON/Mail-SpamAssassin-3.2.5.tar.gz
Mail::SPF v2.007 J/JM/JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz
Math::FractionDemo .53 K/KE/KEVINA/Fraction-v.53b.tar.gz
Maypole::Model::CDBI::AsForm .97 T/TE/TEEJAY/Maypole-2.13.tar.gz
Net::Download::Queue::Download Net J/JO/JOHANL/Net-Download-Queue-0.04.tar.gz
Net::Download::Queue::DownloadStatus Net J/JO/JOHANL/Net-Download-Queue-0.04.tar.gz
Net::Route v0.02 T/TE/TEQUETER/Net-Route-v0.02.tar.gz
PML::Storable VERSION P/PJ/PJONES/PML-0.4.1.tar.gz
PPresenter v1.17 M/MA/MARKOV/PPresenter-1.17.tar.gz
SMS::Handler::Blackhole Revision L/LU/LUISMUNOZ/SMS-Handler-0.01.tar.gz
SMS::Handler::Dispatcher Revision L/LU/LUISMUNOZ/SMS-Handler-0.01.tar.gz
SMS::Handler::Email Revision L/LU/LUISMUNOZ/SMS-Handler-0.01.tar.gz
SMS::Handler::Invoke Revision L/LU/LUISMUNOZ/SMS-Handler-0.01.tar.gz
SMS::Handler::Ping Revision L/LU/LUISMUNOZ/SMS-Handler-0.01.tar.gz
SMS::Handler::Utils Revision L/LU/LUISMUNOZ/SMS-Handler-0.01.tar.gz
Tk::JListbox .01 D/DJ/DJBERG/Tk-JListbox-0.02.tar.gz
Tk::SearchDialog v36 R/RK/RKIES/Tk-Workspace-1.75.tar.gz
Tk::Shell v36 R/RK/RKIES/Tk-Workspace-1.75.tar.gz
Note: These might not be the real version data, but it is what the PAUSE
indexer creates and therefore CPAN.pm uses.
It's not as much as I thought.
Frank
John Peacock
> I'd like to be able to "round-trip" a version any which way
>
> * set it via package NAME VERSION
> * statically parse it and get the same thing back
> * eval "use Foo $version" and succeed
> * get the same thing back from Foo->VERSION
> * give it to version->new() and get back the same thing.
>
> I have posted some sample code that shows cases that work and that fail.
>
> http://gist.github.com/245765
I'll take a look at this tonight...
John
David Golden
In part, my "wishlist" is to harmonize how $VERSION is defined, how
$VERSION is statically parsed by EU::MM->parse_version and
Module::Build::ModuleInfo, how $VERSION is specified to use(), what
gets returned by UNIVERSAL::VERSION and what version->new($version)
gives.
I'd like to be able to "round-trip" a version any which way
* set it via package NAME VERSION
* statically parse it and get the same thing back
* eval "use Foo $version" and succeed
* get the same thing back from Foo->VERSION
* give it to version->new() and get back the same thing.
I have posted some sample code that shows cases that work and that fail.
-- David
John Peacock
> In part, my "wishlist" is to harmonize how $VERSION is defined, how
> $VERSION is statically parsed by EU::MM->parse_version and
> Module::Build::ModuleInfo, how $VERSION is specified to use(), what
> gets returned by UNIVERSAL::VERSION and what version->new($version)
> gives.
OK, to start with the core Perl code uses a completely unique parser in
S_force_version and friends, different from the version.pm-derived code
in util.c. This is part of the core that I didn't touch when I
integrated version.pm and hence it doesn't follow the same rules as the
version object code.
In particular, it uses Perl_scan_num, which will eat underscores without
recourse. It also uses the old method of creating a dual-var (PV and NV
forms) and uses SvNOK_on to "hint" that this is a version. This will
work "most of the time", but those edge cases (especially surrounding
v-strings) are precisely why I wrote version.pm in the first place.
If we want to have One True version parsing, I'd think we would all
prefer that we have one piece of code for both version.pm and
use/package. I may actually have a patch to this code on my other box
to unify both streams; I'll look in a minute.
But I wanted to point this out now, before we go any further down this
hole: Module::Build is using version.pm; I have an unapplied patch
EU::MM to use version.pm in the same way that Module::Build does
(embedded pure Perl or installed version.pm). I would certainly prefer
to make S_force_version use the same parser as the version object code
in the core, so that we can guarantee that all roads lead to the same
destination.
I'm willing to alter Perl_scan_version to, for example, ignore
underscores in alpha versions if requested, or refuse to scan them at
all (if that is preferable). All we need is a consensus on what we want
to allow and what we want to forbid.
John
David E. Wheeler
> OK, to start with the core Perl code uses a completely unique parser in S_force_version and friends, different from the version.pm-derived code in util.c. This is part of the core that I didn't touch when I integrated version.pm and hence it doesn't follow the same rules as the version object code.
>
> In particular, it uses Perl_scan_num, which will eat underscores without recourse. It also uses the old method of creating a dual-var (PV and NV forms) and uses SvNOK_on to "hint" that this is a version. This will work "most of the time", but those edge cases (especially surrounding v-strings) are precisely why I wrote version.pm in the first place.
>
> If we want to have One True version parsing, I'd think we would all prefer that we have one piece of code for both version.pm and use/package. I may actually have a patch to this code on my other box to unify both streams; I'll look in a minute.
>
> But I wanted to point this out now, before we go any further down this hole: Module::Build is using version.pm; I have an unapplied patch EU::MM to use version.pm in the same way that Module::Build does (embedded pure Perl or installed version.pm). I would certainly prefer to make S_force_version use the same parser as the version object code in the core, so that we can guarantee that all roads lead to the same destination.
>
> I'm willing to alter Perl_scan_version to, for example, ignore underscores in alpha versions if requested, or refuse to scan them at all (if that is preferable). All we need is a consensus on what we want to allow and what we want to forbid.
Wouldn't that potentially break some existing modules that use package variables to declare version numbers?
It seems to me that version.pm and `package NAME VERSION` should use the same parser, with rules as specced out by David Golden, but perhaps the old parser should be left for the poor souls still using the package variable declaration form (or whatever context it is that's not using version.pm's parser)?
Best,
David
David E. Wheeler
> The altered behavior would only happen if a flag was set; the default behavior would be unchanged from what it is now. Anyone using
>
> use version; our $VERSION = version->new("1.2.3");
>
> would continue to get exactly what they asked for...
As would folks just doing
our $VERSION = '1.2.3';
or
use vars '$VERSION';
$VERSION = 1.2;
?
> The old parser that I am talking about is only used for:
>
> use package 1.1;
>
> and now
>
> package foo 1.2;
>
> Nothing else uses that codepath at all. What I am suggesting is that I make Perl_scan_version enforce the rules that David Golden (and others) have suggested and only use those limitations when called internally by those two instances listed above.
+1.
Best,
David
John Peacock
> On Nov 30, 2009, at 6:58 PM, John Peacock wrote:
>> I'm willing to alter Perl_scan_version to, for example, ignore
>> underscores in alpha versions if requested, or refuse to scan them
>> at all (if that is preferable). All we need is a consensus on what
>> we want to allow and what we want to forbid.
>
> Wouldn't that potentially break some existing modules that use
> package variables to declare version numbers?
The altered behavior would only happen if a flag was set; the default
behavior would be unchanged from what it is now. Anyone using
use version; our $VERSION = version->new("1.2.3");
would continue to get exactly what they asked for...
> It seems to me that version.pm and `package NAME VERSION` should use
> the same parser, with rules as specced out by David Golden, but
> perhaps the old parser should be left for the poor souls still using
> the package variable declaration form (or whatever context it is
> that's not using version.pm's parser)?
The old parser that I am talking about is only used for:
use package 1.1;
and now
package foo 1.2;
Nothing else uses that codepath at all. What I am suggesting is that I
make Perl_scan_version enforce the rules that David Golden (and others)
have suggested and only use those limitations when called internally by
those two instances listed above.
John
John Peacock
> As would folks just doing
>
> our $VERSION = '1.2.3';
>
> or
>
> use vars '$VERSION';
> $VERSION = 1.2;
>
> ?
Correct. The only time that force_version is called is when the only
token that can be next is a version (cf use/package). Those are just
assignments to a certain scalar; the only time that the version object
code gets called in that case is when UNIVERSAL::VERSION gets called
(either directly as foo->VERSION or indirectly by 'use foo 1.2'). And
even then, the original $VERSION scalar is never itself upgraded; that
was felt to be too magical (though I had a way to do it of course)...
John
David E. Wheeler
> Correct. The only time that force_version is called is when the only token that can be next is a version (cf use/package). Those are just assignments to a certain scalar; the only time that the version object code gets called in that case is when UNIVERSAL::VERSION gets called (either directly as foo->VERSION or indirectly by 'use foo 1.2'). And even then, the original $VERSION scalar is never itself upgraded; that was felt to be too magical (though I had a way to do it of course)...
Sound good to me!
Best,
David
David Golden
> On Nov 30, 2009, at 6:58 PM, John Peacock wrote:
>> I'm willing to alter Perl_scan_version to, for example, ignore underscores in alpha versions if requested, or refuse to scan them at all (if that is preferable). All we need is a consensus on what we want to allow and what we want to forbid.
>
> Wouldn't that potentially break some existing modules that use package variables to declare version numbers?
Yes.
> It seems to me that version.pm and `package NAME VERSION` should use the same parser, with rules as specced out by David Golden, but perhaps the old parser should be left for the poor souls still using the package variable declaration form (or whatever context it is that's not using version.pm's parser)?
I think the current rough "consensus" on IRC is as follows:
* For Version 12, have "package NAME VERSION" be strict and "use NAME
VERSION" (and by extension UNIVERSAL::VERSION) be liberal. Thus,
nothing old breaks, but nothing using the new 'package NAME VERSION"
syntax will break in the future when use()/VERSION() become stricter.
* For Version 14, use NAME VERSION (and UNIVERSAL::VERSION) should be
liberal, but issue deprecation warnings for "bad" version numbers
* For Version 16, use() and VERSION() are strict in what they accept
and die with a syntax error otherwise
This means 'package NAME VERSION' needs to be stricter than it is now
before Version 12 is released. I don't think use() needs to be fixed
to accept things it currently doesn't (like '.01') but it should be
documented more clearly as to what it accepts.
-- David
chromatic
> We ought to put accurate regexps into the documentation, both to directly
> document the syntax and for people to copy into toolchain modules.
+1 to giving regexps which document the syntax, but minus several to
encouraging people to copy and paste them. Here's a nice chance to reduce
fragmentation of syntax; let's reduce fragmentation of implementation as well.
-- c
John Peacock
> * For Version 12, have "package NAME VERSION" be strict and "use NAME
> VERSION" (and by extension UNIVERSAL::VERSION) be liberal. Thus,
> nothing old breaks, but nothing using the new 'package NAME VERSION"
> syntax will break in the future when use()/VERSION() become stricter.
Can do this using what I discussed already elsewhere.
> * For Version 14, use NAME VERSION (and UNIVERSAL::VERSION) should be
> liberal, but issue deprecation warnings for "bad" version numbers
and also version.pm, since someone using version.pm for < 14 needs to
get the same warnings as the code will get with 14+.
> * For Version 16, use() and VERSION() are strict in what they accept
> and die with a syntax error otherwise
ditto for version.pm for the same reasons.
> This means 'package NAME VERSION' needs to be stricter than it is now
> before Version 12 is released. I don't think use() needs to be fixed
> to accept things it currently doesn't (like '.01') but it should be
> documented more clearly as to what it accepts.
I'm sure that use() will get fixed to be consistent about what it
accepts simply by switching to the scan_version parser (in non-strict mode).
I'll start sketching this out tomorrow night...
John
David Golden
<john.p...@havurah-software.org> wrote:
> I'll start sketching this out tomorrow night...
Please coordinate with Zefram and Steffen, as they have already been
working on this a bit and I'd hate to see the three of you duplicating
effort or taking things in diverging directions.
-- David
Aristotle Pagaltzis
> +1 to giving regexps which document the syntax, but minus
> several to encouraging people to copy and paste them. Here's
> a nice chance to reduce fragmentation of syntax; let's reduce
> fragmentation of implementation as well.
So what do you propose instead? Exposing the scan_version routine
to pure Perl code somehow?
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Chromatic
> * chromatic <chro...@wgz.org> [2009-12-01 05:00]:
> > +1 to giving regexps which document the syntax, but minus
> > several to encouraging people to copy and paste them. Here's
> > a nice chance to reduce fragmentation of syntax; let's reduce
> > fragmentation of implementation as well.
> So what do you propose instead? Exposing the scan_version routine
> to pure Perl code somehow?
If the intent is to migrate to a single, consistent form for version numbers
by 5.16, perhaps the best approach is to expose that routine somewhere like
version.pm.
Pros: it's a core module, it will remain a core module, and it already handles
version numbers.
Con: that feature won't be available when installing the CPAN version.pm on
older Perls. Then again, neither is the package VERSION syntax.
-- c
Ben Morrow
>
> * For Version 12, have "package NAME VERSION" be strict and "use NAME
Since this is a discussion about version number confusion: are we
*really* going to start referring to 5.12 as 'Version 12'? The potential
for confusion is enormous.
Ben
Ben Morrow
>
> If the intent is to migrate to a single, consistent form for version numbers
> by 5.16, perhaps the best approach is to expose that routine somewhere like
> version.pm.
>
> Pros: it's a core module, it will remain a core module, and it already handles
> version numbers.
>
> Con: that feature won't be available when installing the CPAN version.pm on
> older Perls. Then again, neither is the package VERSION syntax.
Why not? What you're talking about is just a parsing routine, so the
CPAN version of version could perfectly well provide a version
compatible with what 5.16 does in core.
Ben
David Golden
> If the intent is to migrate to a single, consistent form for version numbers
> by 5.16, perhaps the best approach is to expose that routine somewhere like
> version.pm.
To that end, we would probably want EU::MM->parse_version,
M::B::ModuleInfo, and UNIVERSAL::VERSION to return version objects and
start teaching people to only use Foo->VERSION, and never
$Foo::VERSION to retrieve VERSION during runtime.
If we really want to lock things down, $VERSION needs to become a
reserved global. At the least, it should be readonly and set to 0 by
"package NAME;". Even stricter, attempting to read $VERSION directly
would be a syntax error (after a sufficient deprecation warning
cycle).
-- David
David Golden
Excerpt from "perl -V":
Summary of my perl5 (revision 5 version 11 subversion 2) configuration:
It's been "Version 6", "Version 8", "Version 10" ... this is *old* not
*new*. It's only new (and thus strange) to start referring to it
properly.
-- David
Abigail
As long as $VERSION is allowed to match /^[0-9]{10}$/, I'm happy.
I've given up using dots in any Perl related version numbers long time ago.
Abigail
Zefram
>As long as $VERSION is allowed to match /^[0-9]{10}$/, I'm happy.
What, like
our $VERSION = "0000000100\n";
?
-zefram
Abigail
> On Tue, Dec 1, 2009 at 5:24 AM, Abigail <abi...@abigail.be> wrote:
> > As long as $VERSION is allowed to match /^[0-9]{10}$/, I'm happy.
>
Yes, that means extending the life span of my version numbers with another
1000 years; I do not want to add to the Y10K problem, I go for a Y11K
problem instead.
Expect me to start bugging for $VERSION numbers matching /^[0-9]{10,11}$/
around the year 10950.
Abigail
David Golden
Do you *really* want leading 0 (i.e. octal) version numbers? :-)
-- David
Abigail
No, but $VERSION = "0000010101" may happen, for the first release
I do on Jan 1, 10000 (see my replay to David).
Abigail
Nicholas Clark
But *that* is in the context of "5 version $x subversion $y" and it's
lowercase. You're deliberately using Titlecase here, which makes some sense
as I believe you're trying to make it clear that it's a "special" word.
However I still don't like the use of /version/i anywhere "loose" like this,
as the temptation to then shorten it to v12 is too great. and then v12.0 (and
v12.1), which, well:
$ ./perl -e 'require v11'
Perl v11.0.0 required--this is only v5.11.2, stopped at -e line 1.
$ ./perl -e 'require v11.0'
Perl v11.0.0 required--this is only v5.11.2, stopped at -e line 1.
and, best of all, the documented fun once we get to maint releases:
$ ./perl -lwe 'print version->new(12.0) cmp v12.0'
0
$ ./perl -lwe 'print version->new(12.1) cmp v12.1'
1
For a marketing-compatible string, I preferred the word "release", as in
"Perl 5 release 12"
and then
"Perl 5 release 12 update 1"
(etc)
as:
1: it avoids the massively overloaded v-word.
0: There is no .0 release :-)
Nicholas Clark
Jesse Vincent
On Mon 30.Nov'09 at 22:50:45 -0500, David Golden wrote:
> I think the current rough "consensus" on IRC is as follows:
>
> * For Version 12, have "package NAME VERSION" be strict and "use NAME
> VERSION" (and by extension UNIVERSAL::VERSION) be liberal.
Agreed.
> Thus,
> nothing old breaks, but nothing using the new 'package NAME VERSION"
> syntax will break in the future when use()/VERSION() become stricter.
>
> * For Version 14, use NAME VERSION (and UNIVERSAL::VERSION) should be
> liberal, but issue deprecation warnings for "bad" version numbers
I haven't actually agreed to the deprecation of
"use NAME TRADITIONAL_INSANE_VERSION" yet. I have a sneaking suspicion
that this is going to be less straightforward than one might hope and
don't really want to needlessly break users' code. Don't get me wrong --
It's definitely worth exploring what would happen if this change were
made. I'd love to see versioning get saner, but I'd like to proceed
with extreme caution.
> * For Version 16, use() and VERSION() are strict in what they accept
> and die with a syntax error otherwise
^ See above
> This means 'package NAME VERSION' needs to be stricter than it is now
> before Version 12 is released. I don't think use() needs to be fixed
> to accept things it currently doesn't (like '.01') but it should be
> documented more clearly as to what it accepts.
+1
Jesse Vincent
> >* For Version 14, use NAME VERSION (and UNIVERSAL::VERSION) should be
> >liberal, but issue deprecation warnings for "bad" version numbers
>
> and also version.pm, since someone using version.pm for < 14 needs
> to get the same warnings as the code will get with 14+.
That suggests that upgrading to a newer version.pm will cause code that
used to work right to start complaining (or eventually dying if I read
your comments about 16 correctly). That seems counterproductive.
-Jesse
David Golden
I think I agree with Jesse on this one. version.pm needs to conform
to the Perl version that it is running under rather than try to
backport version semantics to older Perls (any more than it already
is).
So version.pm should only issue deprecations warnings as of Perl 5
[ahem] *release* 14 if we indeed decide to do that. [Happy, Nicholas?]
-- David
John Peacock
> I think I agree with Jesse on this one. version.pm needs to conform
> to the Perl version that it is running under rather than try to
> backport version semantics to older Perls (any more than it already
> is).
There are two competing forces here:
1) You upgrade Perl and your script breaks
2) You upgrade version.pm and your script breaks
I think we can all agree that #2 will happen more often. At least in my
mind, #1 is more important (and yet easier to fix because you will
expect some period of adjustment). Did you see the listing that Frank
Wiegand posted of modules on CPAN that would run afoul of the New World
Version Order? I know that CPAN != the Universe of Perl Scripts, but
that is a remarkably short list of modules that need to be fixed.
Even in our wildest dreams, I would think that two years between 5.12.0
and 5.14.0; plenty of time to fix up modules that warn before they will
die instead.
> So version.pm should only issue deprecations warnings as of Perl 5
> [ahem] *release* 14 if we indeed decide to do that. [Happy, Nicholas?]
version.pm doesn't actually "run" on the Perl's where it is in the core
(5.10.0 and beyond). The CPAN release of version.pm is there only to
provide the same version object behavior to earlier Perl's. As such, I
think that it would be much saner that version.pm works the same,
whether it is in core or not. Having it behave differently, depending
on which release of Perl you are running it on is, in fact, completely
counter to the reason I wrote it in the first place. It shouldn't
matter what release of Perl you are running; version.pm should behave
identically...
John
David Golden
<john.p...@havurah-software.org> wrote:
> Having it behave differently, depending on which release
> of Perl you are running it on is, in fact, completely counter to the reason
> I wrote it in the first place. It shouldn't matter what release of Perl you
> are running; version.pm should behave identically...
John,
With all due respect,, that's what I disagree with. In hindsight, I
think that version.pm should have been strictly limited to providing
an interface to the Perl internals for version number conversion and
comparison.
Having externally available version objects, changing
UNIVERSAL::VERSION on older Perls, and unfortunate adoption of the
awful "use version; our $VERSION = qv(...)" meme has created enormous
confusion and work for toolchain maintainers to keep things working
sanely everywhere.
I fully understand that at the time, it was done with the best of
intentions and I don't say any of this to dismiss all the hard work
that you've put into creating it and maintaining it. But the fact
that it *has* been so much effort for you and others is a big signal
to me that the design is flawed.
I *don't* think we can put the genie back in the bottle, but I'd like
to find ways to restrict what the genie is allowed to get his grubby
mitts on.
-- David
John Peacock
> With all due respect,, that's what I disagree with. In hindsight, I
> think that version.pm should have been strictly limited to providing
> an interface to the Perl internals for version number conversion and
> comparison.
There were no internals to expose until 5.10.0 was released. You are also being
far too parochial in your view; I know of at least one person who uses
version.pm with RPM spec files:
https://rt.cpan.org/Ticket/Display.html?id=48291
though as you can see from the ticket not without their own difficulties.
> Having externally available version objects, changing
> UNIVERSAL::VERSION on older Perls, and unfortunate adoption of the
> awful "use version; our $VERSION = qv(...)" meme has created enormous
That meme exists only because the toolchain didn't include version.pm already
(and because I was arrogant/naive enough to name it qv() in the first place).
And without a version-aware UNIVERSAL::VERSION, it wouldn't work on older Perl's
at all (since the Perl core diddles the SV's directly without any thought to
overloading, etc).
I don't want to continue to fight this protracted battle over the past and what
cannot change now. I just want to move forward. Here are my proposed steps:
1) Add S_force_package_version to toke.c and make it use scan_version instead of
some other handcrafted tokenizer. I did this last night and it was trivial, but
the question is whether it should store a version object or a stringified form
instead; both have advantages and disadvantages and both fail some of the new
comp/package.t tests (which don't follow the regexes in any case).
2) Modify scan_version to accept a "strict" flag, which limits the acceptable
version strings to match the accepted regex. All other callers of scan_version
will set this to false (thus maintaining the status quo). This will necessitate
a CPAN release of course.
3) Change S_force_version to not create those weird dualvar things and strictly
prefer a string form. This should be completely trivial, since the machinery in
the core already knows how to deal with going from strings to version objects
when required.
These are both targeted steps and I feel confident that they are doable in a
short timeframe (depending on $WORK and how much more arguing we have to do on
the list, I hope to have it done by the weekend).
Does this meet with everyone's satisfaction?
John
David Golden
<john.p...@havurah-software.org> wrote:
> I don't want to continue to fight this protracted battle over the past and what
> cannot change now. I just want to move forward.
Agreed.
>Here are my proposed steps:
I'm not close enough to the C code to say and likely don't have the
bandwidth this week to dig into it more deeply. I'll give snap
reactions so take them with a grain of salt.
> 1) Add S_force_package_version to toke.c and make it use scan_version instead of
> some other handcrafted tokenizer. I did this last night and it was trivial, but
> the question is whether it should store a version object or a stringified form
> instead; both have advantages and disadvantages and both fail some of the new
> comp/package.t tests (which don't follow the regexes in any case).
And for now we would use this only for "package NAME VERSION"? And
would use scan_version with the "strict" flag?
> 2) Modify scan_version to accept a "strict" flag, which limits the acceptable
> version strings to match the accepted regex. All other callers of scan_version
> will set this to false (thus maintaining the status quo). This will necessitate
> a CPAN release of course.
What breakage potential does this have? e.g. old version.pm on
5.11.X, new version.pm on old 5.8.8, etc?
> 3) Change S_force_version to not create those weird dualvar things and strictly
> prefer a string form. This should be completely trivial, since the machinery in
> the core already knows how to deal with going from strings to version objects
> when required.
Seems like a good idea.
Overall, I think I'm having a hard time assessing the proposal without
knowing what the alternatives might be and the pros/cons of such
alternatives.
One of the things that bugs me is that version.pm maintains
duplicative code vs core. Would it make sense to make the core
version scanning functions part of the public API for 5.12? And going
forward, on Perl 5.12, have version.pm just use the core API rather
than its own code?
Would that let us freeze the code in version.pm and use it just for
older perls? So that if you're on Perl < 5.12 and you install the
latest, greatest version.pm, you get the version semantics of Perl
v5.10.1. But that's it. After that, if you want version number bug
fixes, you have to upgrade Perl, not version.pm. For Perl 5.12,
version.pm becomes an interface for taking strings, checking them for
validity against the core API, and then wrapping them up as objects
for manipulation.
I'm just rambling at this stage, but I'd like to do something
thoughtful, not knee-jerk. If that means "strict" package NAME
VERSION isn't possible for 5.12, then we should pull package NAME
VERSION and pick this up again in 5.13.
-- David
John Peacock
> And for now we would use this only for "package NAME VERSION"? And
> would use scan_version with the "strict" flag?
Yes.
> What breakage potential does this have? e.g. old version.pm on
> 5.11.X, new version.pm on old 5.8.8, etc?
Close to none. And old version.pm simply won't install on 5.11.x (or
5.12.x for that matter); the core code always takes precedence. New
version.pm from the forthcoming CPAN release will operate exactly as it
has on all Perl releases except 5.11.x/5.12.0, where it will do nothing
(status quo).
> One of the things that bugs me is that version.pm maintains
> duplicative code vs core. Would it make sense to make the core
> version scanning functions part of the public API for 5.12? And going
> forward, on Perl 5.12, have version.pm just use the core API rather
> than its own code?
That is exactly what is going on now (and has been since 5.10.0). The C
code in version.pm's CPAN release is precisely the same C code as exists
in the Perl core. I literally chop out the old block of code from
util.c and read in vutil/vutil.c from the CPAN release and submit a
patch (those few times when I have had to do that). The XS code takes a
little more manual tweaking, because the generated C code from CPAN
contains lots of cruft that we don't want in the Perl core. But that
part has rarely changed because the external interface has been quite
stable.
John
David Nicol
>
> No, but $VERSION = "0000010101" may happen, for the first release
> I do on Jan 1, 10000 (see my replay to David).
>
>
> Abigail
A., do you have any idea what kind of hardware you might be running on then?
--
intake, compression, power, exhaust, repeat.
Nicholas Clark
> On Tue, Dec 1, 2009 at 4:39 AM, Abigail <abi...@abigail.be> wrote:
> >
> > No, but $VERSION = "0000010101" may happen, for the first release
> > I do on Jan 1, 10000 (see my replay to David).
> >
> >
> > Abigail
>
> A., do you have any idea what kind of hardware you might be running on then?
I doubt it. But parrot 7992.0 will be released 17 days later.
Nicholas Clark
Abigail
> On Mon, Dec 07, 2009 at 01:19:58PM -0600, David Nicol wrote:
> > On Tue, Dec 1, 2009 at 4:39 AM, Abigail <abi...@abigail.be> wrote:
> > >
> > > No, but $VERSION = "0000010101" may happen, for the first release
> > > I do on Jan 1, 10000 (see my replay to David).
> > >
> > >
> > > Abigail
> >
> > A., do you have any idea what kind of hardware you might be running on then?
I'm not sure, but it will have at least 2 floppy drives!
>
> I doubt it. But parrot 7992.0 will be released 17 days later.
>
And Perl6^WRakudo will still be finished by Christmas.
Abigail
Paul LeoNerd Evans
Abigail <abi...@abigail.be> wrote:
> On Mon, Dec 07, 2009 at 07:32:02PM +0000, Nicholas Clark wrote:
> > On Mon, Dec 07, 2009 at 01:19:58PM -0600, David Nicol wrote:
> > > On Tue, Dec 1, 2009 at 4:39 AM, Abigail <abi...@abigail.be> wrote:
> > > >
> > > > No, but $VERSION = "0000010101" may happen, for the first release
> > > > I do on Jan 1, 10000 (see my replay to David).
> > > >
> > > >
> > > > Abigail
> > >
> > > A., do you have any idea what kind of hardware you might be running on then?
...
>
> And Perl6^WRakudo will still be finished by Christmas.
You think they'll still celebrate Christmas by then? Perhaps they'll have
to find a new joke...
--
Paul "LeoNerd" Evans
leo...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
John Peacock
ticket:
1) Patch toke.c to use scan_version for `package NAME VERSION` -
completed (I can send it tonight if desireable).
2) Add $version::STRICT and $version::LAX regexes to version.pm - I will
definitely send my revised suggestions tonight (they're on the laptop).
$LAX corresponds to the existing version.pm behavior and $STRICT is a
greatly reduced space of acceptable forms (as discussed already). I'm
trying to write a new test that goes through all of the suggested forms
and make sure that the regexes match.
3) Create common is_valid_version (suggestions for a better name
appreciated) that will be shared between CPAN version.pm code and core
version code. This will implement in C the regexes described above.
This gets called from the toke.c patch above with the "strict" flag set
and the normal version object codepath runs as "lax".
4) Release an alpha version.pm to CPAN with #2 and #3 implemented (by
the weekend?).
By using is_valid_version(), the amount of code that needs to change
_now_ in the main version object code is greatly minimized. I can deal
with the improvements to alpha handling later.
How does that sound? Do we have a rough schedule for drop dead date on
5.12.0???
John
Jesse
On Thu, Dec 17, 2009 at 03:04:50PM -0500, John Peacock wrote:
> To update this ticket, I have a revise plan of attack to resolve this
> ticket:
>
> Do we have a rough schedule for drop dead date on 5.12.0?
I've been trying to hammer that out. There are some other serious issues
that need sorting out. Given that the alternative for "package VERSION"
is to pull the feature back out (per xdg) until 5.14, it'd be very nice
to get your work in. I'd _love_ to have it in for 5.11.3 on Sunday if
you think that's plausible.
The next step of freeze will be "showstoppers and doc patches only".
If you (or any of you reading this) have a reason I should push that
line in the sand later than December 25, please ping me off list with
your rationale.
Best,
Jesse
> John
--
John Peacock
> Given that the alternative for "package VERSION" is to pull the
> feature back out (per xdg) until 5.14, it'd be very nice to get your
> work in. I'd _love_ to have it in for 5.11.3 on Sunday if you think
> that's plausible.
I will make my best effort. I'll send the first patch tonight (which
does everything except enforce the stricter parsing).
John