'images-resize' task moves images

[wiseman]

The images-resize task puts all resized images in the out-dir ("public" by default), which was surprising to me.

I use subdirectories to organize content, keeping images and pages together. E.g.

resources
├── 2019-05-01-figuring-out-whats-overhead
│  └── 2019-05-01-figuring-out-whats-overhead.md
└── public
   └── 2019-05-01-figuring-out-whats-overhead
      ├── 3ff1.png
      └── vrs-options.png

If I don't use the images-resize task, this generates the following structure in target:

target
└── public
   └── 2019-05-01-figuring-out-whats-overhead
      ├── figuring-out-whats-overhead.html
      ├── 3ff1.png
      └── vrs-options.png

The images are copied to the corresponding location in target.

If I add this task:

(perun/images-resize :resolutions #{800})

I end up with this structure:

target
└── public
   ├── 3ff1_800.png
   ├── vrs-options_800.png
   └── 2019-05-01-figuring-out-whats-overhead
      ├── figuring-out-whats-overhead.html
      ├── 3ff1.png
      └── vrs-options.png

It seems like images-resize changes the default behavior that files will be copied to a location in target that corresponds to their location in resources. This feels surprising and less useful than putting the resized images in the corresponding output locations for the original images.

I understand a potential workaround would be to specify :out-dir for the task, but I don't know how to do that without adding a separate images-resize task for each subdirectory, which feels somewhat onerous given the default behavior without images-resize doesn't require any per-subdirectory tasks.

[allentiak]

@wiseman
Thanks for reporting this!
Could you please mention which perun version are you using?

[wiseman]

I'm using 0.4.3-SNAPSHOT.

[allentiak]

Thanks! Good that you're using the latest published version. Now, let's make sure it's not a regression... Could you try to reproduce this with previous releases* and report your findings fees each of them, please? You just need to change the perun version used by boot accordingly. *List of published versions: https://clojars.org/perun

…

[wiseman]

0.4.2-SNAPSHOT:
It almost works. It seems like it's trying to keep resized images with the original images, but unfortunately there's an extra level of public in the output path.

target/public/2019-05-01-figuring-out-whats-overhead
target/public/2019-05-01-figuring-out-whats-overhead/3ff1.png
target/public/public/2019-05-01-figuring-out-whats-overhead/3ff2_800.png

Versions older than 0.4.2-SNAPSHOT give the same behavior as 0.4.2-SNAPSHOT.

[allentiak]

So, if I understood correctly, the bug seems to be triggered *only* in 0.4.3-SNAPSHOT and "almost" triggered in 0.4.2-SNAPSHOT and *all* previous versions? Or are there other versions that trigger it? Again: could you please explicitly name which are the previous versions you have tried and the results in each case? There are five of them: - 0.4.3-SNAPSHOT: ? - 0.4.2-SNAPSHOT: ? - 0.4.1-SNAPSHOT: ? - 0.4.0-SNAPSHOT: ? - 0.3.0: ?

[allentiak]

I have edited my previous comment. Please check it again.

[wiseman]

Yes. 0.4.3-SNAPSHOT has the behavior I Initially described, putting all resized images in public.

The behavior of versions 0.4.2-SNAPSHOT, 0.4.1-SNAPSHOT, 0.4.0-SNAPSHOT, and 0.3.0 is as I described here, putting resized images in a location that mirrors the location of the original image, except with an extra, erroneous level of public.

[allentiak]

Thanks for your confirmation! I will take a look at this during the following days and let you know.