Re: Module::Build 0.30 is released
On Tue, Sep 30, 2008 at 6:33 AM, Steve Hay [EMAIL PROTECTED] wrote: Thanks, applied to bleadperl as 34446. Two local changes remain: Change 32357 by [EMAIL PROTECTED] on 2007/11/17 04:19:47 Skip Module::Build ppm test -- not ready for prime time on VMS. (ppm.t) Change 32351 by [EMAIL PROTECTED] on 2007/11/16 23:43:46 Silence ill-behaved or failing Module::Build tests on VMS. (test_type.t and xs.t parts only--the tilde.t part appears to have been superseded by code in 0.30. Please can you check that, Craig?) I'll look into it. I think those were band-aids to expedite getting 5.10.0 out the door and what's coming from upstream now will fix at least some of the problems we had then.
Re: Module::Build 0.30 is released - ppm.t on VMS depends on Archive::Tar patch.
On Wed, Oct 1, 2008 at 12:00 PM, Steve Hay [EMAIL PROTECTED] wrote: Blead is now updated to Archive-Tar-1.39_04 in #34452. One local change remains in blead: Change 32352 by [EMAIL PROTECTED] on 2007/11/16 23:46:13 The new Archive::Tar tests are TODO on VMS for reasons unrelated to the security issue for which they are testing. Well, that's a desperate-sounding and evasive commit message if I've ever seen one. And the evidence suggests I have seen this one. I'll take a look and see if the evasion is still necessary.
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
True, but it's FAR more palatable to say Just upgrade ONCE, and you'll never have to think about it again compared to upgrading continuously. Adam K 2008/9/30 Matt S Trout [EMAIL PROTECTED]: If the world upgraded regularly, Module::Build wouldn't be such a disaster anyway :)
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
2008/9/30 Matt S Trout [EMAIL PROTECTED]: If the world upgraded regularly, Module::Build wouldn't be such a disaster anyway :) Adam Kennedy wrote: True, but it's FAR more palatable to say Just upgrade ONCE, and you'll never have to think about it again compared to upgrading continuously. As long as we're talking platitudes, why don't we just say you never have to upgrade! In fact, you never even have to install the software, magic ponies inside your computer will just know when you need it and go get it for you. [1] Also everyone gets a million dollars and a pet dragon. [1] I anticipate the Acme::Magic::Pony auto-installer on CPAN by Monday. -- 'All anyone gets in a mirror is themselves,' she said. 'But what you gets in a good gumbo is everything.' -- Witches Abroad by Terry Prachett
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
Michael G Schwern wrote: 2008/9/30 Matt S Trout [EMAIL PROTECTED]: If the world upgraded regularly, Module::Build wouldn't be such a disaster anyway :) Adam Kennedy wrote: True, but it's FAR more palatable to say Just upgrade ONCE, and you'll never have to think about it again compared to upgrading continuously. As long as we're talking platitudes, why don't we just say you never have to upgrade! In fact, you never even have to install the software, magic ponies inside your computer will just know when you need it and go get it for you. [1] Also everyone gets a million dollars and a pet dragon. Sorry, that was a first-thing-in-the-morning post. I've totally lost track of the thread. -- 191. Our Humvees cannot be assembled into a giant battle-robot. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
making latest.pm smaller
Ok, enough of the 13 list CC. #Eric Wilhelm wrote: # from Ken Williams use latest 'Module::Build'; # Knows to look in inc/bundled/ Um, isn't that 'inc/inc_*', or did I miss a memo? Yeah, latest.pm is currently looking in any inc/inc_* for bundled stuff, but that strikes me as kind of dumb actually. I don't know why I used _ as a namespace separator when the filesystem already has a perfectly good / (and the like). Well, it isn't a separator so much as a prefix, but I'm thinking perhaps it should be inc/Module-Build-0.30/ so the path to the bundled version is more explicit - and embedding the version number in that path means we don't have to scan the file of the embedded module. I would then suggest that the usage in Build.PL be: use inc::latest 'Module::Build' = 0.30; and then we should do eval(use $mod $ver) in _load() to back-up the version check with perl's use(). Currently there is no assertion about what $mod-VERSION actually loads. So, if you're bundling something, A) you know what version it is and B) if the yield-to-newer logic somehow misses that what it found is actually older then we'll be in for a bumpy ride which might end at $inexplicable_error_message_12. Implicit in this is an assumption that the author will use a tool to perform the bundling+modify Build.PL and that they will run *disttest* before shipping. This allows: 1. no opendir/readdir and thus _search_bundled() is _check_bundled() 2. only one file needs to be scanned by _version() (which could probably be rolled into _search_inc()) All that said, version.pm is already pretty short and the only issues I currently see are: 1. doesn't assert the required minimum version (e.g. 0.30) 2. _version() should maybe return 0 if it fails to open the file. Though #2 might be pathological and finding a directory (if it is actually a directory -- oops we're missing that check (hmm, #3?)) in @INC with a file named like a module where we can't read it is ... interesting. Has anyone tried that? One final note: # TODO: doesn't handle coderefs or arrayrefs or objects in @INC, but # it probably should I don't think there's a clean general way to deal with that because you'll potentially end up in the situation of needing to unload the module(s) if the coderef loads it. If things come to trying to yield to a new version of a module in a coderef, I think the best thing we can do is just to use the known-good bundled version. (Leaving the owner of said coderef to sort out their own mess - or e.g. detect the loading of inc::latest and deal with it that way.) So, s/TODO/NOTE/ and s/should/shouldn't/? --Eric -- Minimum wage help gives you minimum service. --David Schomer --- http://scratchcomputing.com ---
