Proposal: more aggressive feature flags about image HOT 4 OPEN

I took a look at the build timings for this crate, and one thing that stood out was that about 3/4 of total compilation time was consumed by only a few features:

• webp - which is fixed by image-rs/image-webp#67 (and will be included in the next image-webp release)
• avif - which actually already only enables AVIF encoding (decoding is behind an additional flag because it needs a C dependency)
• rayon - not encode/decode specific, just enables some helper methods that use rayon
• exr - external crate with combined encoding/decoding functionality (and no features to separate them)

from image.

This split likely wouldn't decrease the number of dependencies by very much. The reason is that generally we use the same crate for both encoding and decoding. And even within those crates, a lot of the dependencies will be shared. Compression libraries generally provide both compression and decompression code paths, checksums are the same whether you're writing or validating, etc.

I totally understand where you're coming from in wanting to keep distinct dependencies to an absolute minimum. Given the extremely broad scope of the crate, that's something we unfortunately cannot fully cater towards. We do try to limit to reputable crates and a fair number of dependent crates are actually part of the same image-rs org (and thus don't add anyone new to trust). But that's only one factor to consider. We also care about functionality, performance, robustness, etc.

from image.

Indeed, just removing avif and rayon gave me roughly 20s faster --release compile times, and reduced my dependencies in Cargo.lock by more than 400 lines.

from image.

The main advantage this would bring is a decrease in dependencies, and sub-sequentially compilation times

For me the advantage stops at "decrease in dependencies"

I am looking to create a software that I deploy on my public facing (very valuable to me) production server. I want as few dependencies as I can get.

I came here browsing crates that can help me (scaling Jpeg/PNG and or stitching Jpeg/PNG) and a very important criterion is the quantity of dependencies.

OT It is a weakness in the Rust ecosystem that it is generally so liberal with pulling in arbitrary crates. It is a nightmare from my perspective as I do not want to expand the attack surface on my server more than I absolutely have to.

Love your work - I fully understand if my requirements do not mesh with yours.

from image.