Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Re^3: Why $FIle::Find::prune = 1 returns used only once warning

by hippo (Bishop)
on Apr 17, 2021 at 12:11 UTC ( #11131404=note: print w/replies, xml ) Need Help??

in reply to Re^2: Why $FIle::Find::prune = 1 returns used only once error
in thread Why $FIle::Find::prune = 1 returns used only once error

While their packager can fix and I think does add as a dependency these missing core modules, many users do not use the packaged version since they want a current version, which leads to this issue.

There is nothing to prevent you from declaring File::Find as a dependency of your module. I always try to include core modules as dependencies when I release a dist as it avoids precisely this problem. It also means that I don't have to worry about p5p removing modules from core at a later date.

BTW, the Name "File::Find::prune" used only once: possible typo at... message you receive is not an error, it is merely a warning.


Replies are listed 'Best First'.
Re^4: Why $FIle::Find::prune = 1 returns used only once warning
by stevieb (Canon) on Apr 17, 2021 at 15:14 UTC
    It also means that I don't have to worry about p5p removing modules from core at a later date.

    I wholeheartedly agree with this (listing current core modules as dependencies explicitly).

      Explicitly listing core modules as dependencies has another benefit: CPAN Testers smokeboxes will report the versions of all modules declared as dependencies. While "core only" modules have versions that can be inferred from Perl's version, many modules are now "dual life" and could be updated separately from the Perl core in an installation. Listing them all as dependencies will cause the versions actually used to appear in CPAN test reports.

Re^4: Why $FIle::Find::prune = 1 returns used only once warning
by h2 (Beadle) on Apr 18, 2021 at 20:12 UTC

    This program has a fairly unique set of core requirements, one of which would be to never be packaged as a module, since that would then defeat another of its core requirements, to be installable and upgradeable on almost anything out there, within reason, without any dependency on anything beyond Perl 5/7, and a tiny subset of Core Modules, the fewer the better. Perl has allowed it to meet all those goals, with flying colors.

    It would be fair to say I'm not a Perl programmer, I use Perl 5 because it was by far and away the best, and literally only, choice of language in existence to meet all the program's core requirements, so I might better be termed a Perl wrangler, in that, I wrangle Perl to get it to do what I want, while learning Perl more along the way so I can be a better wrangler and get even more stuff to work. This is turning out absolutely fantastically, by the way, but I'm still not a 'Perl programmer', but I am very very glad the Perl project has the internal discipline that lets Perl be literally the only thing in the world that could be used for this purpose. The fact Perl 5 is blazingly fast, particularly once I learned some key Perl native concepts which I found very difficult to get my head around, still do, certainly does not hurt matters at all.

    The other issue is that in fact, File::Find is NOT a dependency, it's in a subset of modules that are not required in any way unless the user runs a very specific action, which 99.99% (probably less than that) of users will never do. It's what we call in Debian a 'recommends', that is, something that if you want to do x or y, you can add so you can do x or y. I distinguish fairly strictly between 'dependencies' and 'recommends' because that really matters in this case, NOTHING that is not strictly required for the program to run should ever be a 'dependency' since that would block and hinder its utility. There are a range of such recommends, all of which get handled internally by error handlers, which then tell the user politely, hey, if you want to do this advanced feature, you are missing this Perl Module, so can't do that, sorry.

    Also, I've run execution optimizers on this fairly frequently, and the initial loading of modules is a non zero, non trivial performance hit, which is another reason not to load them until required, there's no reason to slow execution loading something that 99.99+% of users will never ever use, and don't even know exists as a feature unless they read the man pages, and even then, wouldn't in general do. It never ceases to amaze me how I can continuously squeeze out more optimizations by doing more advanced Perl techniques, still have not found the end of that, though I'm approaching it, but it's not there yet. Though maybe I am closer than I think, since some of the optimizations I've considered recently would really conflict with maintaining the code, and having it be clean and easy to use.

    Some distributions, I believe rpm/redhat/fedora are one, do not support the concept of 'recommends', their package managers only handle dependencies, which leads to real bloat in package installs since they tend to pull in all kinds of junk that is absolutely not required or a dependency, I know that is this case with this program, the Fedora packager includes as dependencies things that are not only not dependencies, but, which if installed, actually can force the os into installing stuff that it has no business installing, desktop stuff on a server, for example. FreeBSD is also guilty of doing this, which is unfortunate.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11131404]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (2)
As of 2022-07-03 20:54 GMT
Find Nodes?
    Voting Booth?

    No recent polls found