Fork me on GitHub
#perun
<
2019-05-23
>
wiseman00:05:27

one question is what images-resize should do with source images that are not under public. i kinda think they should not be moved to public

wiseman00:05:36

i guess the rule should be that if out-dir is not specified, keep the resized images with the original. otherwise, put them in out-dir. i can do that 🙂

wiseman00:05:10

(i figured i’d talk about this here since it’s relevant to perun, this channel is very low traffic, and i was hoping maybe someone who knew more about the internals would have some advice)

bhagany00:05:13

so the thing about this is that the correct output path seems differently to everyone

bhagany00:05:39

that said, it does look like I intended the parent-path option in resize-paths to allow you to do what you want

bhagany00:05:07

this could be exposed in the task, or the idea behind this design is that it's easy for you to hook into perun's machinery with your own tasks - a my-image-resize would be easy to write, for instance

bhagany00:05:48

I'd caution against messing too much with the default handling of out-dir. it was tricky to get it so that everyone involved at the time was happy, and modifying only one task is going to result in a confusing inconsistency

wiseman01:05:29

i’m hoping any changes will be limited to the images-resize task, which is hard to see as being very useful in its current state except in very limited circumstances--since it will happily overwrite images that happen to have the same name but exist in different subdirectories. a quick check of the real world examples in the readme doesn’t turn up any sites that use images-resize.

wiseman01:05:15

this definitely is something that could run into people’s differing expectations

wiseman01:05:26

and speaking of parent-path, yeah, a smallish change of just moving that binding down into the reduce function actually gives the behavior i’d expect (almost)

bhagany01:05:50

Yeah it’s the changing of just one thing that worries me, as it might mess with consistency between tasks — out-dir should work the same everywhere

bhagany02:05:50

I don’t have the correct behavior loaded into my cache though, so it’s very possible that this is a bug (aka inconsistent with out-dir handling in other tasks)

wiseman02:05:58

i think it might be inconsistent, just based on the observation that foo/2019-05-22-woo.md gets rendered into public/foo/woo.html, even though it appears that the markdown task has "public" as the default :out-dir.

wiseman02:05:48

(edited to fix a path)

bhagany02:05:26

okay yeah, if that's the case I'd call it a bug

wiseman02:05:04

like the message says, there’s probably a better way of doing this, but in the spirit of setting out something that’s wrong as a way to motivate someone to come up with a better way… 🙂 https://github.com/hashobject/perun/pull/235

bhagany02:05:05

I think the default out-dir should remain "public", again for consistency. I don't think I understand your use-case though. do you want, say, markdown to go somewhere under public/ but not the images?

wiseman02:05:47

i just want resized images to stay next to their sources, wherever they are, if i don’t specify otherwise. so if i have public/images/src.jpg, the result should be target/public/images/src_{resolutions}.jpg.

wiseman02:05:00

the specific use-case was to support keeping posts and their assets in their own subdirectories.

wiseman02:05:59

i guess i need to rework this a little based on the assumption that markdown has the correct behavior wrt subdirectories

bhagany02:05:56

ah, okay, so you have a public directory in your input path

bhagany02:05:45

are your markdown files also in public in your input?

bhagany02:05:12

hrm ... this is ringing a bell. I feel like I remember handling the case where the out-dir would be repeated, like public/public/foo.html

bhagany02:05:23

feels related

wiseman02:05:51

right, that was the behavior of versions previous to 0.4.3-SNAPSHOT (at least through 0.3.0)--an extra level of public

wiseman02:05:15

i know this because i was asked to check the behavior in every version of the past 3 years 🙂

bhagany02:05:25

hahahaha, i'm sorry

wiseman02:05:07

(i haven’t been putting markdown files in public on the input side, but i was thinking i might try that)

bhagany02:05:02

fwiw, I am pretty sure that the behavior you're describing for img-resize is correct and consistent, except for the defaulting to nil for out-dir

bhagany02:05:33

in other words, I think if you want src.jpg to end up in the same place as src_{resolutions}.jpg, there are several options: - put src.jpg inside the same directory as your out-dir - sift src.jpg to the location you want it to be after img-resize runs - pass an out-dir to img-resize that matches src.jpg's input location

bhagany02:05:31

I've got to run, but I'll check back, probably tomorrow

wiseman02:05:55

all right, thanks for the input