By the way, my reason for preferring to not make core dependencies
explicit was not the ancient bug, but a "fast fail" argument. It went
like this:
1. If a core dependency is missing, the set up must be broken, probably
due to accidental deletions, mistaken ad-hoc changes, etc.
2. In that case, the best thing to do is to fail
2a. as quickly as possible; and
2b. in a way that makes it as easy as possible to identify the real
reason for the problem.
From that point of view, failing to find the module at install time was
the right thing to do.
I've come around to the new way of thinking, but this was my strongest
reason for adhering to the old one.
-- jeffrey
On 05/23/2014 07:04 PM, Aristotle Pagaltzis wrote:
* Jeffrey Kegler <[email protected]> [2014-05-23 20:00]:
Comments welcome.
There was once upon a time a long-standing bug in CPAN.pm wherein it
would not fail sanely if the user asked it to install a module that
listed core modules from newer perls as dependencies, but would download
a new perl and proceed to futilely try to install it. In that era, it
was imperative to not list core modules as dependencies, and to list the
requisite perl version instead.
But that was a bug, and it was fixed. So that time is long, long past.
(A decade at this point? I no longer even recollect.) Only that habit
has hung on. (Or maybe it is not habit but a universally obvious idea
that occurs to each new Perl programmer anew, independently? Anyway.)
Nowadays, not only is there no reason not to list every single module
you depend on, but in fact, in these days of the core unbundling modules
like Module::Build and CGI (to name some high-profile removals only), it
is actively a good idea to list every single dependency, be it core or
not. Otherwise, a future release of perl might break your module.
I have a draft article on the matter of declaring dependencies that for
years I have been threatening to publish, and really need to complete
one of these days. The long and short of it is that making dependency
resolution for your distribution work 100% reliably, both now *and* in
the future, requires that you declare dependencies on every single thing
you `use` or `require` (or otherwise load), even if that module happens
to ship with core or together with some other module you already depend
on. (The article is about showing why in detail.)
If I were declaring dependencies manually, I would exempt only `strict`,
`warnings` and suchlike from the dependency list. But it should be noted
that there is no actual reason to exclude even those – merely no reason
not to. In point of fact, if you leave your dependency declarations to
any contemporary release tool such as Dist::Zilla, they will not bother
filtering these things from your dependencies; they will simply list the
whole ball of yarn, pragmata ’n’ all. It causes no issues.
Regards,
--
You received this message because you are subscribed to the Google Groups "marpa
parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
