Vendoring zstd

Gregory Szorc gregory.szorc at gmail.com
Thu Nov 10 18:07:32 UTC 2016


I plan to add support for zstd to Mercurial this release cycle. I don't
think support itself is too controversial. (There will be bikeshedding over
implementation details, of course.)

Since zstd is relatively new and not part of a Python distribution, we
can't rely on its shared libraries being available on systems or even part
of the system packager. In addition, the Python bindings to zstd rely on
zstd APIs that require static linking to access. In addition, said zstd
APIs are not guaranteed stable (which is why they aren't exported). So it
is important for the Python bindings to be compiled against a known version
of zstd. This is why the Python bindings ship the zstd sources and don't
treat zstd as an external dependency. On top of that, the Python bindings
are a bit fluid and targeting multiple versions from Mercurial could be
painful until the API matures.

If we're going to have proper zstd support that "just works," I think we
need to vendor the Python bindings (which includes the zstd sources) into
the hg repo.

I have 2 questions:

1) Is vendoring python-zstandard (
https://github.com/indygreg/python-zstandard) (or at least the parts we
need) acceptable?

2) Should I patchbomb the ~1 MB of sources or should the vendoring
changeset(s) be submitted a different way?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161110/a72654a3/attachment.html>


More information about the Mercurial-devel mailing list