Vendoring zstd

[Augie Fackler]

On Thu, Nov 10, 2016 at 10:07:32AM -0800, Gregory Szorc wrote:
> 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?

It's fine with me. We might want to send a note out to the packaging
list giving them a heads up that:

1) We're doing this
2) We'd appreciate it if they didn't unbundle zstd, given the above

On our end, we should probably degrade gracefully if python-zstandard
isn't available, so that distros can unbundle and just not have the
dependency (at least until the APIs settle down).

> 2) Should I patchbomb the ~1 MB of sources or should the vendoring
> changeset(s) be submitted a different way?

I think for the monster import change, we should probably just have
you send a pull request.


> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel