Compress.copy NotImeplemented — needs libz-rs-sys deflateCopy

[dimaqq]

zlib-py/src/lib.rs

Lines 447 to 451 in f6b6540

	fn copy(&self) -> PyResult<Compress> {
	Err(PyNotImplementedError::new_err(
	"Compress.copy not yet supported — needs libz-rs-sys deflateCopy",
	))
	}

Since this is reachable from valid Python code, this will have to be done.

c0 = zlib.compressobj()
prefix = c0.compress(b"common prefix")

c1 = c0.copy()
c2 = copy.copy(c0)
c3 = copy.deepcopy(c0)

[robsdedude]

I had a look at this, but got stuck. libz-rs-sys uses z_stream structs while the rust API uses Deflate and Inflate which wrap zlib_rs::deflate::DeflateStream zlib_rs::inflate::InflateStream respectively as a private field. These two can be transmuted to and from z_stream, but that alone doesn't get us anywhere when we want to convert between z_stream and Deflate/Inflate.

TL;DR: maybe I've missed it, but it appears there's no bridge (without relying on internals of zlib-rs) from its Rust to its C API.

I suggest to either:

• Get the maintainers of zlib-rs to agree to expose copy functions in the Rust API. (prefered)
• Shout yolo, pin the exact version of zlib-rs and start to rely on its internals. At that point, it'd probably be the easiest to enable the __internal-api feature (which libz-rs-sys itself uses). (only really an option for a PoC)

N.B. zlib_rs::deflate and zlib_rs::inflate are also private unless the feature __internal-api is enabled.

[robsdedude]

I'm currently toying around with a branch where I vendor and patch libz-rs to provide the required Rust APIs. In case somebody is interested: https://github.com/robsdedude/zlib-py/tree/feat/copy . I've managed to get the test to pass 🥳

I'd like to get the APIs merged upstream into libz-rs though as the vendoring approach doesn't seem ideal to me.