Skip Menu |
 

This queue is for tickets about the CPAN-Changes CPAN distribution.

Report information
The Basics
Id: 89932
Status: open
Priority: 0/
Queue: CPAN-Changes

People
Owner: Nobody in particular
Requestors: KENTNL [...] cpan.org
Cc: ether [...] cpan.org
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.25
Fixed in: (no value)



Subject: Version parsing so lax it basically accepts anything
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
X-RT-Interface: Web
Message-ID: <rt-4.0.18-16909-1383249285-1465.0-0-0 [...] rt.cpan.org>
X-RT-Original-Encoding: utf-8
Content-Type: multipart/mixed; boundary="----------=_1383249285-16909-2"
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 0
Content-Disposition: inline
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: binary
Content-Length: 1506

A according to the spec, the only valid values for version are legal $versions.

However, the implementation is much more lax in this regard, and essentially permit arbitrary strings to be considered valid versions, as long as it is preceeded by a decimal, and it parses and renormalises this as-is without complaint.

Some people ( e.g.: Moose https://metacpan.org/changes/release/ETHER/Moose-2.1105-TRIAL#L4 ) have been using this notation, for reasons I believe are basically they expected it would work, and they tried it and it worked, and thus assumed it was somehow supported.

And as the attached test demonstrates, practically any characters are valid, and get parsed as versions:

So this seems like the following things are needed:

1. The Spec needs to be clarified what is, and what isn't legal in this regard, the spec says "Just match $version::LAX" , but this *much* more lax than that.

2. The code itself should either error or warn upon parsing unsupported version data like this. ( at least, for some of these example usecases )

3. Normalized output should be spec conforming "somehow", maybe with ->serialize() defaulting to strict behaviour and additional parameters required to make serialize emit non-spec-conformant data.

Some people are interested in having -TRIAL as being a supported part of versions, but until the spec says that is legal, they will not implement it as such

Subject: changes.pl
MIME-Version: 1.0
Content-Type: application/x-perl; name="changes.pl"
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline; filename="changes.pl"
Content-Transfer-Encoding: base64
Content-Length: 468
Download changes.pl
text/x-perl 468b
#!/usr/bin/env perl use strict; use warnings; use utf8; use open ':std', OUT => ':utf8'; use CPAN::Changes; my $changes = CPAN::Changes->load_string(<<"EOF"); 0.1-TRIAL 2013-08-01 - test 0.10-TRIAL 2013-08-01 - test 0.001-TRIAL 2013-08-01 - test 0.ABCDEDF 2013-08-01 - test 0.→.→^ 2013-08-01 - test 1ℒ 2013-08-01 - test EOF use Data::Dump qw(pp); for my $release ( $changes->releases ) { pp $release; } print $changes->serialize;
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-16909-1383249285-1465.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-16909-1383249285-1465.0-0-0 [...] rt.cpan.org>
Content-Type: text/html; charset="utf-8"
Message-ID: <rt-4.0.18-18526-1383249377-733.89932-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 144
Lol, looks like RT is no good at UTF8 encoding, make sure you download that script instead of copy-pasting it unless you want mojibake output =)
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-16909-1383249285-1465.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-16909-1383249285-1465.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-16909-1383249667-889.89932-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 593
Download (untitled) / with headers
text/plain 593b
On 2013-10-31 12:54:45, KENTNL wrote: Show quoted text
> A according to the spec, the only valid values for version are legal > $versions. > > However, the implementation is much more lax in this regard, and > essentially > permit arbitrary strings to be considered valid versions, as long as > it is > preceeded by a decimal, and it parses and renormalises this as-is > without > complaint.
See also http://www.dagolden.com/index.php/2191/real-versions-on-cpan/ for other real-world examples you might want to use in testing. But really, all you should have to do is run the string through version::is_lax.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-16909-1383249285-1465.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-16909-1383249285-1465.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-20092-1432363923-227.89932-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 568
Download (untitled) / with headers
text/plain 568b
To be specific, the parser will accept anything that starts with $version::LAX. Additionally, support for -TRIAL in parts of the API was explicitly added. To some extent, this is a compromise between strictness and usefulness. I'd like to separate the spec from the parser, because while I think it's useful to have the spec as a recommendation, the module itself isn't much use unless it can handle data that exists in the wild. So how loose do we think the parser should be? Things with -TRIAL or ->RC0 etc on the end are going to be difficult to fully specify.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.