I take a similar attitude to modules which use Graphviz's dot: Check for availability at the start of Build.PL/Makefile.PL, and fail fast.
On Sunday, 25 May 2014 10:36:42 UTC+10, Jeffrey Kegler wrote: > > 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] <javascript:>> > [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.
