# from David Golden
# on Friday 11 September 2009 17:39:
>> o Off-line: For those of us who work on machines with no mini CPAN
>> and no internet access,...
>
>As an end-user, it will "work"
No, you're going to run into troubles with dependencies just like you
would with an EU::MM-based Makefile.PL. This whole scheme is just to
bring along the configure_requires modules for Build.PL time to
provide "just works" for old CPAN clients. For installation, you need
to bring the whole dep tree along in tarball form and work through it
(and run the tests!) in the right order. We're not doing that.
> As an author...
>The issue is dependency resolution of configure_requires.
>... but there's no foolproof way to
>tell that Devel::CheckLib requires it and that it needs to be bundled.
> Module::ScanDeps is an option, but it can miss things.
We could probably load Devel::TraceDeps into author-mode in inc::latest.
That would catch every module that got used when Build.PL ran. The
trick is then just to decide where to put them (inc/inc_andalso/) but
you'll need to deal with the fact that they're not being loaded
via "use inc::latest 'whatever'". Maybe D::TD would just be a check?
> The safest, most robust thing to do is to get the Devel::CheckLib
> META.yml and get the 'requires' list from there
And this will fail if it makes any architecture-dependent choices during
configure, but that's how things go.
Of course, configure_requires gets over that easily because it will
follow standard dep-resolution procedure.
But if you really want your dist to work on an old client you could
build-up your inc/ with the extra deps (assuming that they are pure
perl.) This is the kind of thing where I'm inclined to say that you're
on your own though -- so the DWIM doesn't need to deal with that.
>We could implement various heuristics and 9/10 times it will work
>fine. Or, we can say that you can't "Build distdir" unless you have
>access to a CPAN. You can develop and test and do all that, but the
>actual build of a dist directory couldn't happen.
>
>Ultimately, I don't think putting that constraint on authors is too
>great a burden.
I would rather that we do it without a net connection, or at least
ensure that it's the same combination of stuff that the author is
using. This is partly why I lean toward a .packlist-based scheme. You
can't really make it work at all without pure-perl modules, and there
are a few other constraints to the whole scheme. Thus, I think we
should optimize for solving the Module::Build case (90% solution.)
In other words, at some point you reach a problem where it can't be done
or is maybe just somewhat difficult. I suggest that whatever we try to
do automagically should stop well short of that point.
--Eric
--
hobgoblin n 1: (folklore) a small grotesque supernatural creature that
makes trouble for human beings
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
