What I tell you back: you probably don't need it, you're just being very, very lazy, which will cost later in bugs in those dependencies, and it's not that easy to fix a bug in a dependency.
Additionally, it's not that difficult to make a package with that dependency. I routinely do so, both for things other people wrote and for my code. Sure, it's not as easy as adding a line in package.json, but there should be some friction in adding a library to a project, so the library would justify itself. Keeping many dependencies is very expensive in the long run, but short-term is somewhat beneficial. Look at how it works for Node.js and gems and Python packages: every library needs its own `map()' function implementation (or anything else similarly trivial), so typcial application requires few dozens of other libraries.
Personally, I use NPM because NPM does local versioning, so I will never end up in dll hell.
Also, NO, NEVER WRITE A PACKAGE THAT HAS EXPLICIT KNOWLEDGE OF A DISTRO PACKAGE MANAGER. If you do, you are being an asshole. If you want to depend on a distro specific package manager, document your dependencies, and just expect them to be there. Because not everybody uses your package manager.
Also, I am a hobbyist programmer. I also know that git was created by Linus Torvalds, it's a DVCS (although Torvalds calls it an SCM), and it's based on a DAG (directed acrylic graph), which is a directed graph with no directed cycles, and excellent for modelling causal relations. I can explain to you the difference between a rebase and a merge. I know that git uses SHA-1 hashes to identify check-ins internally, as a data security feature. I know that checkins and other objects are stored in the .git folder at the repository's root directory. I know that these objects are garbage collected, although the frequency at which they are escapes me. I know that, despite common belief, git commits are immutable, but also that the git history is not. I know that git was inspired by BitKeeper, after the incident that caused the linux source to be moved away from that system, because Linux got fed up with tarballs and patches, and hates CVS with a fanatical passion. I know that git had three design goals: distributed, fast, and guarantees that you get the same bits out that you put in. And I've have several years of causal experience with git, using probably one tenth of its functionality.
I may not be able to recite git's internals at you, but I know it's features (to an extent), I know the tools, and I know the reasoning. And the functionality sure as heck isn't magic.