Skip Menu |
 

This queue is for tickets about the IO-Pager CPAN distribution.

Report information
The Basics
Id: 127342
Status: open
Priority: 0/
Queue: IO-Pager

People
Owner: Nobody in particular
Requestors: david.wheeler [...] iovation.com
Cc:
AdminCc:

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



Subject: v0.40 Version Inconsistent
Date: Thu, 11 Oct 2018 13:12:36 -0400
To: bug-io-pager [...] rt.cpan.org
From: "David E. Wheeler" <david.wheeler [...] iovation.com>
Download (untitled) / with headers
text/plain 572b
When you unpack the v0.40 tarball, which is named IO-Pager-0.40.tgz and seems to contain the v0.40 release of IO-Pager, it expands into a directory named IO-Pager-0.4. This inconsistency seems to be due to using a number for the version instead of a string. It can be fixed with this patch: --- a/lib/IO/Pager.pm +++ b/lib/IO/Pager.pm @@ -1,5 +1,5 @@ package IO::Pager; -our $VERSION = 0.40; #Untouched since 0.40 +our $VERSION = '0.40'; #Untouched since 0.40 use 5.008; #At least, for decent perlio, and other modernisms use strict;
Subject: Re: [rt.cpan.org #127342] v0.40 Version Inconsistent
Date: Thu, 11 Oct 2018 22:19:05 -0400
To: bug-IO-Pager [...] rt.cpan.org
From: Jerrad Pierce <belg4mit [...] pthbb.org>
Download (untitled) / with headers
text/plain 127b
They're equivalent values though :-P But something to keep in mind before v.5 I'm surprised you find the new release so fast.
Subject: Re: [rt.cpan.org #127342] v0.40 Version Inconsistent
Date: Fri, 12 Oct 2018 09:20:05 -0400
To: bug-IO-Pager [...] rt.cpan.org
From: "David E. Wheeler" <david.wheeler [...] iovation.com>
On Oct 11, 2018, at 10:39 PM, belg4mit@pthbb.org via RT <bug-IO-Pager@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=127342 > > > They're equivalent values though :-P > But something to keep in mind before v.5 > > I'm surprised you find the new release so fast.
But they’re not the same. I found this because I have a nightly job that builds RPMs for our CentOS servers. The RPM toolchain assumes that the directory a tarball unpacks into has the same name as the tarball itself. I learned of this issue when the build job failed. This demonstrates the difference between a string and a float version: Show quoted text
> perl -E 'say version->new(1.40); say version->new("1.40")'
1.4 1.40 Some places it’s treated as a string, such as in your tarball name). Other places treated as as a float, such as in your META.json file: https://metacpan.org/source/JPIERCE/IO-Pager-0.40/META.json#L52 This inconsistency causes problems. Most folks don’t expect to go from 1.39 to 1.4. Furthermore, let’s say I wanted to look up the distribution via the MetaCPAN API (which, FWIW, my nightly job in fact does). If I’ve read the version from the META.json file, I know to make a query like this: curl -XPOST https://fastapi.metacpan.org/v1/file/_search -d '{ "query": { "filtered":{ "query":{"match_all":{}}, "filter":{"and":[ {"term":{"module.name":"IO::Pager"}}, {"term":{"module.version":0.4}} ]} }}, "fields":["release"] }' Which returns the results. But if I looked at the the page on the MetaCPAN site: https://metacpan.org/release/IO-Pager Oh, I see “IO-Pager-0.40” there. So if I queried for version "0.40" above, it returns no results. Even though if I use the full distribution name, it works! https://fastapi.metacpan.org/v1/release/JPIERCE/IO-Pager-0.40 But this doesn’t: https://fastapi.metacpan.org/v1/release/JPIERCE/IO-Pager-0.4 There are a slew of places in which this difference in the handling of stringified and numerified versions can be handled inconsistently by Perl and the toolchain. I guarantee there are tools that think 1.4 is lower than 1.39, because 4 < 39. The best solution is always declare versions as strings: our $VERSION = '0.40’; Then the whole problem goes away. But if one decides to always use a float, the only way around this issue is to never have trailing 0s, but always have the same precision. So 1.40 would be out, but 1.41 is fine. I recommend switching to strings: --- a/lib/IO/Pager/Buffered.pm +++ b/lib/IO/Pager/Buffered.pm @@ -1,5 +1,5 @@ package IO::Pager::Buffered; -our $VERSION = 0.40; +our $VERSION = '0.41'; use strict; use base qw( IO::Pager ); --- a/lib/IO/Pager.pm +++ b/lib/IO/Pager.pm @@ -1,5 +1,5 @@ package IO::Pager; -our $VERSION = 0.40; #Untouched since 0.40 +our $VERSION = '0.41'; #Untouched since 0.40 use 5.008; #At least, for decent perlio, and other modernisms use strict; This change will permanently fix broken toolchain and packaging systems, as long as one uses strings from here on in.
Subject: Re: [rt.cpan.org #127342] v0.40 Version Inconsistent
Date: Mon, 15 Oct 2018 12:04:20 -0400
To: bug-IO-Pager [...] rt.cpan.org
From: "David E. Wheeler" <david.wheeler [...] iovation.com>
Download (untitled) / with headers
text/plain 237b
FYI, here are the changes I had to make to my build script to work around this issue: https://github.com/iovation/rpmcpan/commit/bac6c49 Yes, the inconsistency of numeric versions in Perl is ugly. Best not to use them. Best, David
Subject: Re: [rt.cpan.org #127342] v0.40 Version Inconsistent
Date: Mon, 15 Oct 2018 13:28:51 -0400
To: bug-IO-Pager [...] rt.cpan.org
From: Jerrad Pierce <belg4mit [...] pthbb.org>
Download (untitled) / with headers
text/plain 342b
v0.42 Will fix this, but I'm awaiting acceptance of my megapatch/commit bits to Term::Pager so that I can include it as an option in IO::Pager; I also have a few bugs to work out with my preferred implementation... I should probably push these up to githib, along with previous versions, but github no longer plays nicely with my machine :-/
Subject: Re: [rt.cpan.org #127342] v0.40 Version Inconsistent
Date: Mon, 15 Oct 2018 13:47:19 -0400
To: bug-IO-Pager [...] rt.cpan.org
From: "David E. Wheeler" <david.wheeler [...] iovation.com>
What’s the problem with GitHub? Maybe I could help? I’m a committer on the project, IIRC… D


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.