This module has a --system-zstd option in setup.py, but it doesn't work as expected, because the bundled zstd copy (#48) is compiled anyway. I found that it's almost possible to delete the bundled zstd, but one has to remove all references to the internal zstd POOL_* APIs. Does this module really need to (ab)use internal zstd APIs? Could the multi-threaded mode be implemented in some other way? Maybe using the standard Pool interface with multiprocessing.dummy?

My use-case is packaging zstandard for use in Fedora and we have, like many other distributions, specific provisions against bundling, mostly for security reasons in our packaging guidelines. I'd really appreciate it if I could simply rm -rf zstd and still have the module build with --system-zstd and link to the shared system libzstd then.