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.