Allow for generating a reduced set of images for development

[datapolitical]

So I have a ton of files on my site that I never expect to change, but which are being regenerated every time because my build environment doesn't preserve originals. My solution for some is going to be to just replace the originals with the generated files, but I can't do that for one directory that is routinely updated.

What would be nice is an option to tell JPT to look at the originals directory and then check a "persistent-cache" (the way it does with the files in _site) where images that have been generated can be stored without corrupting the directory structure of the originals.

There may be a better way to handle this issue (aside from changing my build environment) but I'm not sure what it is.

[datapolitical]

Actually, just tried putting only the generated images in the folder and that did not work. What's the right solution here?

[rbuchberger]

The right solution is to preserve the generated files. Is this your development environment that runs a fresh build every time? Is there no way to change that?

JPT follows a few rules - it never modifies the source images, and the generated images follow a naming scheme based on the settings used to create them.

[datapolitical]

Yea I have a build action on GitHub that doesn’t preserve any build files: https://github.com/datapolitical/chrisfnicholson.github.io/blob/main/.github/workflows/build-jekyll.yml

my past solution was just to copy the generated files (from Jekyll-webp) back into the source directory. That doesn’t work here.

it adds about 4 minutes to the production build time, which is annoying, but it adds 20 minutes on my MacBook, which I would really like to reduce.

My next thought would be to tell it to ignore the drinks folder (where the images never change), and copy the generated files to back to source, but I’m not sure the picture tag will still work at that point...

[rbuchberger]

Github actions can be configured to cache folders, described here, though it's not entirely meant for this use case and it gets deleted if not used for a week.

v2 changes the image handling backend which significantly speeds up build times. I'm hoping to have a pre-release version of that up in the next week or two. I'm also considering the option to easily cut down the number of generated images for development and only go whole-hog when building for production.

Copying the generated images back to source won't work. The only thing that will work is keeping the generated images in place.

[datapolitical]

Yea I have that set up for some things, I’ll see if I can add it for those folders.

and a Dev flag would be nice cause 90% of the time you don’t need every size available.

[rbuchberger]

To expand on the new title: I'd like to allow people to easily only generate a small number of images in their local development environment, and then generate the full set when building for production.

[sdumetz]

Maybe just reuse the ability to provide a development _config.yml : Add a config_file configuration option that defaults to "picture"

Then change (I think):

    PictureTag.site.data.dig('picture', 'presets', name) 
#to :
    PictureTag.site.data.dig( PictureTag.site.config['config_file'], 'presets', name) 

Then you have to create a mirror config file where less images get generated.

Implementation should be trivial but generating development-specific images might hide issues until after deployment so I think this might cause more problems than it solves.

[Commenter25]

I think this might cause more problems than it solves.

An alternative that might be less potentially problematic: what if instead of generating a different set of images, what if the same images were just made faster? As in, force encoder effort levels to 0, generating inefficient images very quickly; then in production mode, set them back to whatever they're set to in picture.yml. This would be particularly useful for sites with AVIF, which easily take the longest. This would allow making something for development, and then it can go full bore for the actual production version. Could be a simple boolean option like fast_encode.