Thread: [Module::Build] M::B and version.pm
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: John P. <jpe...@ro...> - 2006-02-19 15:36:58
|
Ken, et al - Please withdraw from consideration my patch to include version.pm support in Module::Build 0.28. Now that we have made the obj->numify() change, M::B will correctly handle the case where the module author uses version.pm, and everything else will still work correctly. It is clear that a lot more thought has to go into when/how to handle the YAML dependency question, and I would much rather get 0.28 shipped (for my own selfish reasons), and fight that other battle later. Thanks John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747 |
|
From: David E. W. <da...@ki...> - 2006-02-22 20:13:53
|
On Feb 19, 2006, at 07:37, John Peacock wrote:
> Please withdraw from consideration my patch to include version.pm
> support in
> Module::Build 0.28. Now that we have made the obj->numify()
> change, M::B will
> correctly handle the case where the module author uses version.pm, and
> everything else will still work correctly.
Actually, I'm running into an issue with the numify() support: it's
misnaming my distributions! I have a module that uses version
internally:
our $VERSION = version->new('0.0.1');
However, when I build a distribution with it, the tarball isn't named
Foo-Bar-0.0.1.tar.gz. It's named Foo-Bar-0.000001.tar.gz!
Is there a way 'round this? Maybe dist_version could store the
version object instead of the numified representation, so that the
string format (v0.0.1) can be used where appropriate, and the
numified representation (0.000001) can be used where appropriate?
Thanks,
David
|
|
From: John P. <jpe...@ro...> - 2006-02-22 20:20:55
|
David E. Wheeler wrote:
> Actually, I'm running into an issue with the numify() support: it's
> misnaming my distributions! I have a module that uses version internally:
>
> our $VERSION = version->new('0.0.1');
>
> However, when I build a distribution with it, the tarball isn't named
> Foo-Bar-0.0.1.tar.gz. It's named Foo-Bar-0.000001.tar.gz!
That's what you asked it to do ('v0.0.1' => 0.000001). That's also what
PAUSE will use internally as the version for indexing purposes.
> Is there a way 'round this? Maybe dist_version could store the version
> object instead of the numified representation, so that the string format
> (v0.0.1) can be used where appropriate, and the numified representation
> (0.000001) can be used where appropriate?
Until M::B includes version object support internally, I don't see any
better way around it. Currently M::B immediately changes any version
object into a simple scalar (via numify now). Unless and until M::B has
a way to keep the version object around for later usage, it is going to
have to be either numify() *or* stringify() (and the latter has
significant problems).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
|
|
From: David E. W. <da...@ki...> - 2006-02-22 20:27:39
|
On Feb 22, 2006, at 12:21, John Peacock wrote:
> Until M::B includes version object support internally, I don't see
> any better way around it. Currently M::B immediately changes any
> version object into a simple scalar (via numify now). Unless and
> until M::B has a way to keep the version object around for later
> usage, it is going to have to be either numify() *or* stringify()
> (and the latter has significant problems).
Okay, but there does seem to be a conversion problem. Witness this test:
use strict;
use version;
use Test::More tests => 1;
my $v = version->new('0.0.1');
my $nv = version->new($v->numify);
is $nv, $v;
The output:
1..1
not ok 1
# Failed test in /Users/david/bin/try at line 8.
# got: '0.000001'
# expected: 'v0.0.1'
# Looks like you failed 1 test of 1.
Shouldn't they be the same?
Best,
David
|
|
From: John P. <jpe...@ro...> - 2006-02-22 20:40:36
|
David E. Wheeler wrote:
> Okay, but there does seem to be a conversion problem. Witness this test:
>
> use strict;
> use version;
> use Test::More tests => 1;
>
> my $v = version->new('0.0.1');
> my $nv = version->new($v->numify);
> is $nv, $v;
>
> The output:
>
> 1..1
> not ok 1
> # Failed test in /Users/david/bin/try at line 8.
> # got: '0.000001'
> # expected: 'v0.0.1'
> # Looks like you failed 1 test of 1.
>
> Shouldn't they be the same?
Nope. is() performs an implicit stringification of each term and then
performs a string comparison (i.e. no overload magic possible). Replace
that last line with:
cmp_ok( $nv,'==', $v);
and it will work as you expected. No, I don't like it, but I don't have
any choice...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
|
|
From: David E. W. <da...@ki...> - 2006-02-22 20:46:50
|
On Feb 22, 2006, at 12:40, John Peacock wrote: > Nope. is() performs an implicit stringification of each term and > then performs a string comparison (i.e. no overload magic > possible). Replace that last line with: > > cmp_ok( $nv,'==', $v); > > and it will work as you expected. No, I don't like it, but I don't > have any choice... I see. So there's no way for '0.000001' to be converted back to '0.0.1'? What about a method on version.pm that will give the three-part version string no matter what the original version number was? Best, David |
|
From: John P. <jpe...@ro...> - 2006-02-22 20:54:34
|
David E. Wheeler wrote: > I see. So there's no way for '0.000001' to be converted back to '0.0.1'? > > What about a method on version.pm that will give the three-part version > string no matter what the original version number was? That would be $v->normal, but that isn't the problem. The problem is that M::B doesn't want to carry around the version object as an object, and so has to convert into something non-magical. If Ken and/or Randy want to tell me whether they want to hold 0.28 for the fully debugged and thought out version object support, I will do what I can to get that working. *FULL DISCLOSURE* - My wife is out of town on a medical emergency and I have kid duty by myself for now, so it is all I can do to crawl into bed after reading to the kids (5 and 10). I don't know how long it will take me to produce a working patch that everyone will be happy with... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748 |
|
From: David E. W. <da...@ki...> - 2006-02-22 21:37:34
|
On Feb 22, 2006, at 12:54, John Peacock wrote: > That would be $v->normal, but that isn't the problem. The problem > is that M::B doesn't want to carry around the version object as an > object, and so has to convert into something non-magical. Right. > If Ken and/or Randy want to tell me whether they want to hold 0.28 > for the fully debugged and thought out version object support, I > will do what I can to get that working. I think that this is the way that it will have to go before long. What with Damian encouraging everyone to use version.pm for their version objects, we're already seeing distributions such as "Class- Std-v0.0.8" (what's with the "v"?). After the next release of Module::Build, if a new version of Class::Std is released, it will be "Class-Std-000009". Some might find that annoying. And why very few modules use version.pm now, I would expect that to start to change in the next year. Best, David |
|
From: Randy W. S. <ml...@th...> - 2006-02-22 23:31:02
|
David E. Wheeler wrote: > On Feb 22, 2006, at 12:54, John Peacock wrote: > >> That would be $v->normal, but that isn't the problem. The problem is >> that M::B doesn't want to carry around the version object as an >> object, and so has to convert into something non-magical. > > Right. > >> If Ken and/or Randy want to tell me whether they want to hold 0.28 for >> the fully debugged and thought out version object support, I will do >> what I can to get that working. > > I think that this is the way that it will have to go before long. What > with Damian encouraging everyone to use version.pm for their version > objects, we're already seeing distributions such as "Class-Std-v0.0.8" > (what's with the "v"?). After the next release of Module::Build, if a > new version of Class::Std is released, it will be "Class-Std-000009". > Some might find that annoying. And why very few modules use version.pm > now, I would expect that to start to change in the next year. I'm no expert in regards to versions, and I don't know as much as I should or need to to make an intelligent decision. My most general opinion on the issue: 1) especially with the recent hoopla, Module::Build must produce results equivalent to MakeMaker unless there is a very good reason to be different; 2) it must produce usable results (eg META.yml) that can be used by CPAN.pm, CPANPLUS, etc.; and 3) it must work with perl versions back to 5.005x. I don't know if this means operating in different modes under different circumstances, eg different behavior on perl 5.10 vs 5.6, or different behavior in the presence of version.pm, or different behavior depending on whether the distribution in question 'use version;', etc. This is just an opinion. Any resemblance to an actual requirement or solution are unintentional. Please consult Ken for approval or validation. =) Randy. |
|
From: David E. W. <da...@ki...> - 2006-02-23 00:12:37
|
On Feb 22, 2006, at 13:37, David E. Wheeler wrote:
> I think that this is the way that it will have to go before long.
> What with Damian encouraging everyone to use version.pm for their
> version objects, we're already seeing distributions such as "Class-
> Std-v0.0.8" (what's with the "v"?). After the next release of
> Module::Build, if a new version of Class::Std is released, it will
> be "Class-Std-000009". Some might find that annoying. And why very
> few modules use version.pm now, I would expect that to start to
> change in the next year.
In the meantime, I'm just getting sneaky in my subclass of
Module::Build:
sub dist_version {
local *version::numify = sub { shift };
return shift->SUPER::dist_version(@_)
}
Muah-ha-ha! :-)
It works for me as a workaround for now, 'till version.pm support is
integrated into Module::Build.
Best,
David
|
|
From: Ron S. <ro...@sa...> - 2006-02-22 22:16:09
|
On Wed, 22 Feb 2006 15:54:52 -0500, John Peacock wrote: Hi John > crawl into bed after reading to the kids (5 and 10). I don't know > how long it will take me to produce a working patch that everyone > will be happy with... Don't stress yourself (any more than usual :-) over this. I for one can wait= until a real solution is found before a so-called solution is shipped. The current situation is just a mess. -- Cheers Ron Savage, ro...@sa... on 23/02/2006 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company |
|
From: Ken W. <ke...@ma...> - 2006-02-25 21:30:42
|
On Feb 22, 2006, at 2:54 PM, John Peacock wrote: > If Ken and/or Randy want to tell me whether they want to hold 0.28 > for the fully debugged and thought out version object support, I > will do what I can to get that working. I'm quite happy to wait until after 0.28 to address it. -Ken |
|
From: Randy W. S. <ml...@th...> - 2006-03-07 02:17:04
|
Ken Williams wrote: > > On Feb 22, 2006, at 2:54 PM, John Peacock wrote: > >> If Ken and/or Randy want to tell me whether they want to hold 0.28 for >> the fully debugged and thought out version object support, I will do >> what I can to get that working. > > I'm quite happy to wait until after 0.28 to address it. Me too! If it's ok, I'm going to mark all my version related mails done, and we'll start fresh on 0.28? If none are pressing errors for this release? John, I appreciate your perseverance and all the advice and help on this issue. Randy. |
|
From: John P. <jpe...@ro...> - 2006-03-07 02:38:00
|
Randy W. Sims wrote: > Ken Williams wrote: >> I'm quite happy to wait until after 0.28 to address it. > > Me too! If it's ok, I'm going to mark all my version related mails done, > and we'll start fresh on 0.28? If none are pressing errors for this > release? Me three! Let's try and revisit this after 0.28 is out (and hopefully the smoke has died down on blead). > John, I appreciate your perseverance and all the advice and help on this > issue. It's my own damn fault for becoming the expert on structured version objects. :( John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747 |
Thanks for helping keep SourceForge clean.
X