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
---------------------------------------------------
