Build failure due to image crate version mismatch

[rajeeshknambiar]

Latest master (eebf676d09abf4) fails to build with following error:

$cargo build
…
error[E0308]: mismatched types
   --> src/lib.rs:213:45
    |
213 |                         Ok(mut bmp) => Some(bmp.as_image()),
    |                                        ---- ^^^^^^^^^^^^^^ expected `DynamicImage`, found `image::dynimage::DynamicImage`
    |                                        |
    |                                        arguments to this enum variant are incorrect
    |
    = note: `image::dynimage::DynamicImage` and `DynamicImage` have similar names, but are actually distinct types
note: `image::dynimage::DynamicImage` is defined in crate `image`
   --> /home/rajeesh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/image-0.24.9/src/dynimage.rs:55:1
    |
55  | pub enum DynamicImage {
    | ^^^^^^^^^^^^^^^^^^^^^
note: `DynamicImage` is defined in crate `image`
   --> /home/rajeesh/.cargo/registry/src/index.crates.io-6f17d22bba15001f/image-0.25.1/src/dynimage.rs:50:1
    |
50  | pub enum DynamicImage {
    | ^^^^^^^^^^^^^^^^^^^^^
    = note: perhaps two different versions of crate `image` are being used?
help: the type constructed contains `image::dynimage::DynamicImage` due to the type of the argument passed
   --> src/lib.rs:213:40

Cargo.lock contains two crates of image, versions 0.24.9 and 0.25.1, probably pulled by different dependent crates.

[Jazzpirate]

Hmm, I can't reproduce this... running rustup update and cargo update in the repository, cleaning the target directory and running cargo build --release builds without errors, and my Cargo.lock only contains image version 0.25.1. Github CI also succeeds.

The Cargo.lock is not pushed to the repo - is it possible you have an older version of the lock file around, and if so, did you try running cargo update?

(btw, if you want to use rustex as a rust crate directly, depending on your use case you might want to switch to the successor here: https://github.com/Jazzpirate/RusTeX - it's significantly more performant, has wider coverage and is to some extent more versatile, it just doesn't have a binary release yet, because I couldn't be bothered with doing any CLI / user interface things yet, and the HTML layout produced has not yet been "fine tuned". I am working on our downstream applications for now until I'm certain that everything works there)

[rajeeshknambiar]

Removing old Cargo.lock indeed fixes the compilation, sorry for the noise.

Thank you for pointing to the new repository. I remember you mention about the rewrite during TUG23, but I was following the changes in this repo. I could build the new code and started playing with it. Would be happy to collaborate :-)

[Jazzpirate]

Great :) the new code should be somewhat documented, which may or may not help in getting started. If you have any questions, suggestions, or even straight-up pull requests let me know :)