hashobject / perun

Programmable static site generator built with Clojure and Boot (HELP NEEDED!)
https://perun.io
Eclipse Public License 1.0
351 stars 38 forks source link

'images-resize' task moves images #233

Open wiseman opened 5 years ago

wiseman commented 5 years ago

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 commented 5 years ago

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

wiseman commented 5 years ago

I'm using 0.4.3-SNAPSHOT.

allentiak commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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:

allentiak commented 5 years ago

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

wiseman commented 5 years ago

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 commented 5 years ago

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