I just noticed this PR was created, so I've just published a new zopfli release to make the required change available without dependency patching 🙂

/q Fix the build errors in this PR.

I'm unable to access the file contents in this PR to diagnose the specific build errors. To help fix the build errors, I would need:

1. The specific error messages from the CI build logs
2. Access to the changed files to see the code that's causing the build failures

Based on the PR description and comments, the likely issues are:

• Dependency version mismatches (zopfli v0.8.3 was just released, but the Cargo.toml may need updating)
• Missing dependency for ppmd-rust with get_ref/get_mut support
• Potential compilation errors in the new get_ref/get_mut implementations

Could you please:

1. Share the specific build error messages from CI
2. Check if Cargo.toml has been updated to use zopfli v0.8.3
3. Verify that ppmd-rust dependency includes the required get_ref/get_mut methods

Alternatively, if you can run cargo build --all-features locally and share the error output, I can provide more specific fixes.

/q Fix the build errors in this PR.

I'm unable to access the file contents and specific build error messages needed to fix the build errors.

To properly fix the build errors, I need either:

1. The specific error messages from the CI build logs (compiler errors, warnings, etc.)
2. Access to view the actual code changes in the modified files

Could you please share:

• The output from cargo build --all-features or the CI build logs showing the specific errors
• Or run cargo clippy --all-features --all-targets and share those results

Common issues in PRs like this that add get_ref/get_mut methods typically include:

• Lifetime parameter mismatches
• Missing trait bounds
• Feature flag configuration issues
• Type inference problems with generic writers

Once I can see the specific error messages, I'll be able to provide targeted fixes.

@roblabla The AI seems to be stuck in a loop trying to fix this PR: every attempted fix breaks the build, and every fix for the build errors reintroduces the bug.

Also I think get_ref should be try_get_ref if we want to be panic!() free

Changed it to return an Option, since Zopfli makes the underlying writer inaccessible anyway (and making it accessible wouldn't make sense, since it's wrapped in a BitwiseWriter that may be buffering part of a byte).

For what it’s worth, Zopfli does allow access to the underlying writer in its latest release, which includes zopfli-rs/zopfli#69. However, you need to call get_ref/get_mut a different number of times to fully unwrap the underlying layers. The following compiles on my end:

diff --git a/src/write.rs b/src/write.rs
index fbb0a736..39323105 100644
--- a/src/write.rs
+++ b/src/write.rs
@@ -200,9 +206,9 @@ pub(crate) mod zip_writer {
                 #[cfg(feature = "deflate-flate2")]
                 Deflater(w) => Some(w.get_ref().get_ref()),
                 #[cfg(feature = "deflate-zopfli")]
-                ZopfliDeflater(_) => None,
+                ZopfliDeflater(w) => Some(w.get_ref().get_ref()),
                 #[cfg(feature = "deflate-zopfli")]
-                BufferedZopfliDeflater(_) => None,
+                BufferedZopfliDeflater(w) => Some(w.get_ref().get_ref().get_ref()),
                 #[cfg(feature = "bzip2")]
                 Bzip2(w) => Some(w.get_ref().get_ref()),
                 #[cfg(feature = "zstd")]
@@ -226,9 +232,9 @@ pub(crate) mod zip_writer {
                     #[cfg(feature = "deflate-flate2")]
                     Deflater(w) => Some(w.get_mut().get_mut()),
                     #[cfg(feature = "deflate-zopfli")]
-                    ZopfliDeflater(_) => None,
+                    ZopfliDeflater(w) => Some(w.get_mut().get_mut()),
                     #[cfg(feature = "deflate-zopfli")]
-                    BufferedZopfliDeflater(_) => None,
+                    BufferedZopfliDeflater(w) => Some(w.get_mut().get_mut().get_mut()),
                     #[cfg(feature = "bzip2")]
                     Bzip2(w) => Some(w.get_mut().get_mut()),
                     #[cfg(feature = "zstd")]

Of course, the caveats about the BitwiseWriter state going out of sync on changes to the underlying writer, or it not having flushed out any remaining bits for the current byte are still valid. But I don't think they are substantially different from those of other DEFLATE encoders.