Thread: [Module::Build] yaml_dump on version objects
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: John P. <jpe...@ro...> - 2006-02-15 19:11:28
Attachments:
yaml_version
|
Dear Perl YAML-heads: I've been trying to integrate version objects into Module::Build (now that I have a pure Perl release) and everything works except that YAML emits lots of warnings when trying to dump version objects: Use of uninitialized value in hash element at /usr/lib/perl5/site_perl/5.8.7/YAML.pm line 283. Use of uninitialized value in string eq at /usr/lib/perl5/site_perl/5.8.7/YAML.pm line 291. ...blah...blah...blah... --- !perl/YAML::Warning code: YAML_DUMP_WARN_BAD_NODE_TYPE msg: "Can't perform serialization for node type " ... I've tried to implement a yaml_dump() sub in the class, but I cannot figure out how to use it (the commented out Bless line just croaks). I've attached my example code (which requires version). TIA 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: John P. <jpe...@ro...> - 2006-02-15 22:05:56
|
John Peacock wrote: > Dear Perl YAML-heads: > > I've been trying to integrate version objects into Module::Build (now > that I have a pure Perl release) and everything works except that YAML > emits lots of warnings when trying to dump version objects: Never mind. Upgrading YAML to current (0.58) works much better and setting $YAML::Stringify does exactly what we want. 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: Ken W. <ke...@ma...> - 2006-02-16 15:35:40
|
On Feb 15, 2006, at 4:06 PM, John Peacock wrote: > John Peacock wrote: >> Dear Perl YAML-heads: >> I've been trying to integrate version objects into Module::Build (now >> that I have a pure Perl release) and everything works except that >> YAML emits lots of warnings when trying to dump version objects: > > Never mind. Upgrading YAML to current (0.58) works much better and > setting $YAML::Stringify does exactly what we want. Is there no way to support YAML 0.35? That's our current YAML prerequisite. -Ken |
|
From: John P. <jpe...@ro...> - 2006-02-16 17:46:21
|
Ken Williams wrote: > > On Feb 15, 2006, at 4:06 PM, John Peacock wrote: >> Never mind. Upgrading YAML to current (0.58) works much better and >> setting $YAML::Stringify does exactly what we want. > > Is there no way to support YAML 0.35? That's our current YAML > prerequisite. Nope. Once you throw an object into the mix, YAML gets very confused. Apply my patch and try it with 0.35 and you will see: 1) a screenful of warnings thrown during the META.yml creation; 2) worse yet, the META.yml is malformed (it doesn't include either a dump of the version object as hash nor the correct stringified representation). I can, with some more difficulty, patch M::B to force a stringification of version objects prior to inserting them into the $node, but it isn't nearly as clean. Is there some overriding reason you are avoiding upgrading the YAML prereq to 0.50 (which in itself isn't even the current rev)? 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: Ken W. <ke...@ma...> - 2006-02-16 17:55:51
|
On Feb 16, 2006, at 11:46 AM, John Peacock wrote: > Is there some overriding reason you are avoiding upgrading the YAML > prereq to 0.50 (which in itself isn't even the current rev)? Good question. I guess not, though this is the first time I think we'd upgrade an auto-feature dependency, and it has just occurred to me that it'll catch people by surprise if they currently have that feature enabled. It will suddenly get non-enabled without much warning. -Ken |
|
From: John P. <jpe...@ro...> - 2006-02-16 18:08:24
|
Ken Williams wrote:
>
> On Feb 16, 2006, at 11:46 AM, John Peacock wrote:
>
>> Is there some overriding reason you are avoiding upgrading the YAML
>> prereq to 0.50 (which in itself isn't even the current rev)?
>
> Good question. I guess not, though this is the first time I think we'd
> upgrade an auto-feature dependency, and it has just occurred to me that
> it'll catch people by surprise if they currently have that feature
> enabled. It will suddenly get non-enabled without much warning.
Can't the 0.28 installer test for the auto-feature already being enabled
*and* whether YAML is new enough and then upgrade that to a mandatory
prereq? It would mean that the auto_feature would still quote 0.35, but
then before running create_build_script, you have to ask if they want to
upgrade YAML *or* disable YAML support. Alternatively, check the
existing auto-feature setting before calling ModuleBuildBuilder and DTRT...
This may be something to consider for future development: conditional
autofeatures that take a coderef for additional processing. In pseudocode:
auto_features => {
YAML_support =>
{
description => "Can write fully-functional
META.yml files",
requires => { YAML => check_yaml() },
},
where check_yaml() returns either true (if the existing version is
already acceptable) or can prompt the user and insert a new requires()
stanza if the user accepts the additional dependency, *or* it returns
false and that auto-feature is disable.
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: Ken W. <ke...@ma...> - 2006-02-16 21:03:57
|
On Feb 16, 2006, at 12:08 PM, John Peacock wrote: > Ken Williams wrote: >> On Feb 16, 2006, at 11:46 AM, John Peacock wrote: >>> Is there some overriding reason you are avoiding upgrading the YAML >>> prereq to 0.50 (which in itself isn't even the current rev)? >> Good question. I guess not, though this is the first time I think >> we'd upgrade an auto-feature dependency, and it has just occurred to >> me that it'll catch people by surprise if they currently have that >> feature enabled. It will suddenly get non-enabled without much >> warning. > > Can't the 0.28 installer test for the auto-feature already being > enabled *and* whether YAML is new enough and then upgrade that to a > mandatory prereq? Yup, it could, and it probably should. I'd just never thought of it before this thread so it doesn't do it yet, and to make things DTRT we should really think through various contingencies - such as what happens when the user has a previously-acceptable YAML installed and is willing to turn off the feature because they don't want to upgrade. I think the various cases could get tricky. I'd prefer to keep the declaration of 'auto_features' purely declarative, and have the checker implement all the necessary decisions rather than sticking functions into the declarations, though. -Ken |
|
From: <in...@tt...> - 2006-02-16 19:50:48
|
Ken, You definitely want to use 0.58+ for your prereqs. For a couple of 0.5x releases there were Spiffy deps etc, but that's all been resolved. Now YAML.pm requires no extra deps. Also with 0.58 I can fix bugs and turn around releases in short order (well depending on the bug ;) Cheers, Ingy On 16/02/06 11:55 -0600, Ken Williams wrote: > > On Feb 16, 2006, at 11:46 AM, John Peacock wrote: > > >Is there some overriding reason you are avoiding upgrading the YAML > >prereq to 0.50 (which in itself isn't even the current rev)? > > Good question. I guess not, though this is the first time I think we'd > upgrade an auto-feature dependency, and it has just occurred to me that > it'll catch people by surprise if they currently have that feature > enabled. It will suddenly get non-enabled without much warning. > > -Ken > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Yaml-core mailing list > Yam...@li... > https://lists.sourceforge.net/lists/listinfo/yaml-core |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-02-17 09:51:27
|
On Thu, Feb 16, 2006 at 12:03:18PM -0800, Ingy dot Net wrote: > Ken, > > You definitely want to use 0.58+ for your prereqs. > > For a couple of 0.5x releases there were Spiffy deps etc, but that's all been > resolved. Now YAML.pm requires no extra deps. You realize that you still have build_requires Test::Base 0.49 and Test-Base requires Spiffy? |
|
From: Chris D. <ch...@cl...> - 2006-02-17 14:33:26
|
On Feb 17, 2006, at 3:51 AM, Yitzchak Scott-Thoennes wrote: > On Thu, Feb 16, 2006 at 12:03:18PM -0800, Ingy dot Net wrote: >> Ken, >> >> You definitely want to use 0.58+ for your prereqs. >> >> For a couple of 0.5x releases there were Spiffy deps etc, but >> that's all been >> resolved. Now YAML.pm requires no extra deps. > > You realize that you still have build_requires Test::Base 0.49 > and Test-Base requires Spiffy? I had the same question, but I then noticed that those are both included in the inc/ dir. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) |
|
From: David G. <da...@hy...> - 2006-02-17 14:55:56
|
Chris Dolan wrote: > On Feb 17, 2006, at 3:51 AM, Yitzchak Scott-Thoennes wrote: > >> On Thu, Feb 16, 2006 at 12:03:18PM -0800, Ingy dot Net wrote: >>> Ken, >>> >>> You definitely want to use 0.58+ for your prereqs. >>> >>> For a couple of 0.5x releases there were Spiffy deps etc, but that's >>> all been >>> resolved. Now YAML.pm requires no extra deps. >> >> You realize that you still have build_requires Test::Base 0.49 >> and Test-Base requires Spiffy? > > I had the same question, but I then noticed that those are both included > in the inc/ dir. But it's still listed in the META.yml file as a build_requires. I think that will cause CPAN/CPANPLUS to try to install/upgrade it, regardless of its presence in inc/. David Golden |
|
From: Chris D. <ch...@cl...> - 2006-02-17 15:04:23
|
On Feb 17, 2006, at 8:55 AM, David Golden wrote: > Chris Dolan wrote: >> On Feb 17, 2006, at 3:51 AM, Yitzchak Scott-Thoennes wrote: >>> On Thu, Feb 16, 2006 at 12:03:18PM -0800, Ingy dot Net wrote: >>>> Ken, >>>> >>>> You definitely want to use 0.58+ for your prereqs. >>>> >>>> For a couple of 0.5x releases there were Spiffy deps etc, but >>>> that's all been >>>> resolved. Now YAML.pm requires no extra deps. >>> >>> You realize that you still have build_requires Test::Base 0.49 >>> and Test-Base requires Spiffy? >> I had the same question, but I then noticed that those are both >> included in the inc/ dir. > > But it's still listed in the META.yml file as a build_requires. I > think that will cause CPAN/CPANPLUS to try to install/upgrade it, > regardless of its presence in inc/. > > David Golden That is correct, but the point is (I believe) that if you don't use CPAN/CP+ then the install will succeed anyway. Just as an experiment, I tried a CPAN install and said NO to Test::Base. The install succeeded. cpan> install YAML ... Running install for module YAML Running make for I/IN/INGY/YAML-0.58.tar.gz Fetching with LWP: ftp://mirrors.kernel.org/pub/CPAN/authors/id/I/IN/INGY/ YAML-0.58.tar.gz CPAN: Digest::MD5 loaded ok Fetching with LWP: ftp://mirrors.kernel.org/pub/CPAN/authors/id/I/IN/INGY/CHECKSUMS Checksum for /root/.cpan/sources/authors/id/I/IN/INGY/ YAML-0.58.tar.gz ok ... CPAN.pm: Going to build I/IN/INGY/YAML-0.58.tar.gz Checking if your kit is complete... Looks good Writing Makefile for YAML ---- Unsatisfied dependencies detected during [I/IN/INGY/ YAML-0.58.tar.gz] ----- Test::Base Shall I follow them and prepend them to the queue of modules we are processing right now? [yes] n ... All tests successful, 17 subtests skipped. Files=32, Tests=415, 47 wallclock secs (39.81 cusr + 2.69 csys = 42.50 CPU) /usr/bin/make test -- OK ... Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) |
|
From: Ken W. <ke...@ma...> - 2006-02-18 05:04:09
|
On Feb 17, 2006, at 9:04 AM, Chris Dolan wrote: > That is correct, but the point is (I believe) that if you don't use > CPAN/CP+ then the install will succeed anyway. Ooh, don't start down that road, man. The 'passthrough' auto-generated Makefile.PL will succeed in manual mode and fail under CPAN, when M::B isn't installed, and look how upset that makes people. -Ken |
|
From: Ingy d. N. <in...@tt...> - 2006-02-18 03:28:43
|
On 17/02/06 01:51 -0800, Yitzchak Scott-Thoennes wrote: > On Thu, Feb 16, 2006 at 12:03:18PM -0800, Ingy dot Net wrote: > > Ken, > > > > You definitely want to use 0.58+ for your prereqs. > > > > For a couple of 0.5x releases there were Spiffy deps etc, but that's all been > > resolved. Now YAML.pm requires no extra deps. > > You realize that you still have build_requires Test::Base 0.49 > and Test-Base requires Spiffy? These are bundled as testing artifacts. You need neither installed on your machine and the YAML dist installs neither. Try installing YAML on a clean Perl. :) Cheers, Ingy |
|
From: Ken W. <ke...@ma...> - 2006-02-18 03:52:47
|
On Feb 17, 2006, at 9:42 PM, Ingy dot Net wrote: > On 17/02/06 01:51 -0800, Yitzchak Scott-Thoennes wrote: >> On Thu, Feb 16, 2006 at 12:03:18PM -0800, Ingy dot Net wrote: >>> Ken, >>> >>> You definitely want to use 0.58+ for your prereqs. >>> >>> For a couple of 0.5x releases there were Spiffy deps etc, but that's >>> all been >>> resolved. Now YAML.pm requires no extra deps. >> >> You realize that you still have build_requires Test::Base 0.49 >> and Test-Base requires Spiffy? > > These are bundled as testing artifacts. You need neither installed on > your > machine and the YAML dist installs neither. It needs to be removed from build_requires, then, because when it's in there, installation tools will think they need to fetch & install it. -Ken |
|
From: Ingy d. N. <in...@tt...> - 2006-02-18 08:20:49
|
On 17/02/06 21:52 -0600, Ken Williams wrote: > > On Feb 17, 2006, at 9:42 PM, Ingy dot Net wrote: > > >On 17/02/06 01:51 -0800, Yitzchak Scott-Thoennes wrote: > >>On Thu, Feb 16, 2006 at 12:03:18PM -0800, Ingy dot Net wrote: > >>>Ken, > >>> > >>>You definitely want to use 0.58+ for your prereqs. > >>> > >>>For a couple of 0.5x releases there were Spiffy deps etc, but that's > >>>all been > >>>resolved. Now YAML.pm requires no extra deps. > >> > >>You realize that you still have build_requires Test::Base 0.49 > >>and Test-Base requires Spiffy? > > > >These are bundled as testing artifacts. You need neither installed on > >your > >machine and the YAML dist installs neither. > > It needs to be removed from build_requires, then, because when it's in > there, installation tools will think they need to fetch & install it. > > -Ken You mean in the META.yml? Module::Install generates that for me. Is it wrong? Cheers, Ingy |
|
From: Ken W. <ke...@ma...> - 2006-02-18 15:58:40
|
On Feb 18, 2006, at 2:34 AM, Ingy dot Net wrote: > On 17/02/06 21:52 -0600, Ken Williams wrote: >> It needs to be removed from build_requires, then, because when it's in >> there, installation tools will think they need to fetch & install it. >> >> -Ken > > You mean in the META.yml? Module::Install generates that for me. Is it > wrong? > Yeah, it's wrong in this case. CPAN reads it to determine dependencies it will need to fetch & install. -Ken |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-02-17 09:47:57
|
On Thu, Feb 16, 2006 at 12:46:34PM -0500, John Peacock wrote: > Ken Williams wrote: > > > >On Feb 15, 2006, at 4:06 PM, John Peacock wrote: > >>Never mind. Upgrading YAML to current (0.58) works much better and > >>setting $YAML::Stringify does exactly what we want. > > > >Is there no way to support YAML 0.35? That's our current YAML > >prerequisite. > > Nope. Once you throw an object into the mix, YAML gets very confused. > Apply my patch and try it with 0.35 and you will see: > > 1) a screenful of warnings thrown during the META.yml creation; > 2) worse yet, the META.yml is malformed (it doesn't include either a > dump of the version object as hash nor the correct stringified > representation). > > I can, with some more difficulty, patch M::B to force a stringification > of version objects prior to inserting them into the $node, but it isn't > nearly as clean. > > Is there some overriding reason you are avoiding upgrading the YAML > prereq to 0.50 (which in itself isn't even the current rev)? The newer YAMLs require 5.6.1 (plus a lot of other dependency-bloat). |
|
From: Ken W. <ke...@ma...> - 2006-02-18 03:57:50
|
On Feb 17, 2006, at 3:47 AM, Yitzchak Scott-Thoennes wrote: > On Thu, Feb 16, 2006 at 12:46:34PM -0500, John Peacock wrote: >> Is there some overriding reason you are avoiding upgrading the YAML >> prereq to 0.50 (which in itself isn't even the current rev)? > > The newer YAMLs require 5.6.1 (plus a lot of other dependency-bloat). > Yeah, M::B targets perls back as far as 5.005_03. The functionality we require from YAML is fairly trivial, just serializing strings & numbers. If YAML itself is too heavyweight for our simple task, maybe we need to consider just reimplementing the parts of it we need. Which we could then release as YAML::SmallSubset or something if desirable. I dunno, none of the options sound fun. -Ken |
Thanks for helping keep SourceForge clean.
X