Skip Menu |
 

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 114295
Status: open
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: nomad [...] null.net
Cc:
AdminCc:

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



Subject: Unexpected result from dist_version_from with underscore
Date: Tue, 10 May 2016 11:18:24 +0200
To: bug-Module-Build [...] rt.cpan.org
From: Mark Lawrence <nomad [...] null.net>
Download (untitled) / with headers
text/plain 1.8k
Software versions (all on Debian): This is perl 5, version 22, subversion 1 (v5.22.1) built for i586-linux-gnu-thread-multi-64int (with 58 registered patches, see perl -V for more detail) L/LE/LEONT/Module-Build-0.4218.tar.gz /home/mark/.direnv/perl5/lib/perl5/Module/Build.pm Installed: 0.4218 CPAN: 0.4218 up to date Ken Williams (KWILLIAMS) kwilliams@cpan.org mark@mlt:~/tmp.ZzaK6XwnsX$ cat lib/Simple.pm package Simple; use strict; use warnings; our $VERSION = '0.0.1_1'; 1; __END__ mark@mlt:~/tmp.ZzaK6XwnsX$ cat Build.PL #!perl use strict; use warnings; use Module::Build; my $builder = Module::Build->new( dist_abstract => 'a simple module', module_name => 'Simple', license => 'GPL_3', dist_author => 'Mark Lawrence <nomad@null.net>', dist_version_from => 'lib/Simple.pm', ); $builder->create_build_script(); mark@mlt:~/tmp.ZzaK6XwnsX$ perl Build.PL Can't find dist packages without a MANIFEST file Run 'Build manifest' to generate one WARNING: Possible missing or corrupt 'MANIFEST' file. Nothing to enter for 'provides' field in metafile. Created MYMETA.yml and MYMETA.json Creating new 'Build' script for 'Simple' version 'v0.0.11' The issue I have is that verion '0.0.1_1' in Simple.pm is detected as 'v0.0.11'. If I use (dist_version => '0.0.1_1') directly then the behaviour is as I would expect. Apparently a decision was made at the Lyon consensus about how version.pm should handle underscores. I do not fully understand what the full ramifications of that decision are. Are versions with underscores still valid: - As a $Module::VERSION? - As a distribution version? If yes, then I would expect Module::Build to extract and report the $Module::VERSION as it appears. Mark -- Mark Lawrence
Download (untitled) / with headers
text/plain 671b
On 2016-05-10 02:18:44, nomad@null.net wrote: Show quoted text
> The issue I have is that verion '0.0.1_1' in Simple.pm is detected as > 'v0.0.11'. If I use (dist_version => '0.0.1_1') directly then the > behaviour is as I would expect.
(comments for the MB developers..) I would think that the version in the tarball name ought to remain '0.0.1_1', but the metadata should normalize the version: { version => '0.0.11', release_status => 'unstable', } Especially since this is a new distribution, I would encourage the author to use ExtUtils::MakeMaker in a Makefile.PL instead of Module::Build, but there is still an issue in Module::Build for us to address.
Subject: Re: [rt.cpan.org #114295] Unexpected result from dist_version_from with underscore
Date: Thu, 12 May 2016 22:22:25 +0200
To: Karen Etheridge via RT <bug-Module-Build [...] rt.cpan.org>
From: Mark Lawrence <nomad [...] null.net>
Download (untitled) / with headers
text/plain 2.7k
On Tue May 10, 2016 at 01:38:54PM -0400, Karen Etheridge via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=114295 > > > On 2016-05-10 02:18:44, nomad@null.net wrote:
> > The issue I have is that verion '0.0.1_1' in Simple.pm is detected as > > 'v0.0.11'. If I use (dist_version => '0.0.1_1') directly then the > > behaviour is as I would expect.
> > (comments for the MB developers..) > I would think that the version in the tarball name ought to remain '0.0.1_1', > but the metadata should normalize the version: > > { > version => '0.0.11', > release_status => 'unstable', > }
Does it really make sense to allow versions to be interpreted in different ways in different places? Because from the '0.0.1 trial 1' point of view '0.0.11' is just simply not the same thing. I worry that there are some unintended consequences such as a distribution being uploaded with a wrong file name (which nearly happened to me). Or it could be that some statistics are wrong somewhere, or cpantesters shows funny names, or I don't know what. I guess because I don't know exactly what situations the normalized or plain strings are used, it seems like madness to me to try and keep track of the context in which each one can be used. Maybe those situations are trivial and could be well documented. Perhaps I'm just rehashing discussion that has already occurred in other threads many years ago. I don't know and I apologise if that is the case. Show quoted text
> Especially since this is a new distribution, I would encourage the > author to use ExtUtils::MakeMaker in a Makefile.PL instead of > Module::Build, but there is still an issue in Module::Build for us to > address.
Oh boy, now I have really come full circle :-( At various times I have gone from MakeMaker to Module::Build to M:B:Tiny to Minilla to Module::Install and then back to Module::Build based either on recommendations or blog posts or specific issues with each one, and now I have your encouragement to return to the source... /offtopicrant If the Perl QA gods are listening this is one topic I would like to see attacked, with gusto, at the next hackathon. Let's pick one, fix all the warts, put depreciation notices in the rest, and get on with things more interesting. Yes, I am volunteering my time somewhere if I know the majority are moving in one direction. I'm sorry I don't have the time (or experience probably) to do a Chad and rewrite the guts of Module::Build or whatever. offtopicrant/ [ My main goal is just to be able to use cpanfiles, semver versioning, and to be able to make multiple developer releases to cpan in between stable releases. Ideally with the developer/trial version reflected in module $VERSION as well as the distribution name. Can anybody point me at the best practice for that? Does -TRIAL1 -TRIAL2 work everywhere? ] -- Mark Lawrence
Download (untitled) / with headers
text/plain 1016b
On Thu May 12 16:22:37 2016, nomad@null.net wrote: Show quoted text
> On Tue May 10, 2016 at 01:38:54PM -0400, Karen Etheridge via RT wrote: >
> > Especially since this is a new distribution, I would encourage the > > author to use ExtUtils::MakeMaker in a Makefile.PL instead of > > Module::Build, but there is still an issue in Module::Build for us to > > address.
> > Oh boy, now I have really come full circle :-( At various times I have > gone from MakeMaker to Module::Build to M:B:Tiny to Minilla to > Module::Install and then back to Module::Build based either on > recommendations or blog posts or specific issues with each one, and > now I have your encouragement to return to the source...
I was also disappointed to see that recommendation. I certainly don't consider MakeMaker to be any less of a dead end than it was 15 years ago when I started creating Module::Build; what's changed is that I'm not personally leading the project anymore, and nobody else responsible for maintaining it seems to like it very much.
Download (untitled) / with headers
text/plain 896b
On Tue May 10 05:18:44 2016, nomad@null.net wrote: Show quoted text
> The issue I have is that verion '0.0.1_1' in Simple.pm is detected as > 'v0.0.11'. If I use (dist_version => '0.0.1_1') directly then the > behaviour is as I would expect.
And likewise 0.01_1 is interpreted as 0.011 (this was always the case as it happens in the parser). The Lyon decision was for symmetry between numeric and semantic versions in that regard. Show quoted text
> Apparently a decision was made at the Lyon consensus about how > version.pm should handle underscores. I do not fully understand what > the full ramifications of that decision are. Are versions with > underscores still valid: > > - As a $Module::VERSION? > - As a distribution version? > > If yes, then I would expect Module::Build to extract and report the > $Module::VERSION as it appears.
They are still valid, but need to be quoted to function properly. Leon


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.