-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom sidecar mako
templates
#1123
Comments
I like this idea.
I don't understand this -- not available from where? Assuming you don't also want also the current XMP sidecar, you could rig this now by editing the file I'll add this to the queue -- should be fairly straightforward to implement. Will need to add the files generated to the update list as you noted and provide a template for the filename so you can customize the output sidecar name. |
Awesome 😄
|
I'm close to having this implemented. Here's the interface so far. Does this meet your use case? Basically, you can provide a mako template, a custom osxphotos template which will be used to render the filename of the sidecar, and flags to either strip excess whitespace and/or excess new lines (which happens with Mako sometimes). The Edit: I also had to add a flag that tells osxphotos what to do when the photo is skipped. With regular sidecars, the sidecar file is still written (or updated or skipped) even if photo is skipped as while the photo may not have changed (causing it to be skipped), the content of the sidecar (which includes metadata) may have changed. For user sidecars, osxphotos won't know if the sidecar should be written or not as it has no knowledge of the contents of the sidecar thus the user must explicitly specify behavior. The options are always write a sidecar for skipped files (WRITE_SKIPED = 1) or never write a sidecar for skipped files (WRITE_SKIPPED = 0). This is definitely an advanced feature but it may be very useful for certain use cases.
|
I believe this is now working. I also updated report writer to indicate which files are user generated sidecars in the report. Works with --update and --cleanup. I need to add tests then will get this pushed out soon. |
* Working on custom sidecar, #1123 * Working on custom sidecar, #1123 * Added custom sidecar example * Added WRITE_SKIPPED argument for --sidecar-template * Updated report writer for user sidecars * Added noqa to long lines in report writer * Initial tests for --sidecar-template * Initial tests for --sidecar-template * Initial tests for --sidecar-template * Completed tests for --sidecar-template * Added json example for --sidecar-template * Added json example for --sidecar-template
Looks awesome! I'll be porting my hacks that were patching the beta template file to use this instead. Happened to notice you have a typo in the docs, you reference both |
I also left a comment about potentially caching the compiled template. |
This is implemented in v0.61.0. I added caching of the template as you suggested and fixed the typos. Please let me know what you think and if this meets your use cases. The Mako sidecar is passed three variables:
There are three example Mako sidecars in the examples directory:
Because the PhotoInfo object is available to the sidecar template, this last example is as simple as: ${photo.json(shallow=False, indent=4)} This is definitely a niche option but as you suggested, it might be very useful for creating and sharing sidecars for specific apps. |
This is great and covers everything I need so far.
The trivial JSON output that I have full control over is super nice. In my case I'm joining photos to some external CSV files that I can lookup records via keys (mostly URLs) that I've added as part of description field. This makes for a great plugin system since you get the full power of python for every photo being processed. I bet you could even do some crazy stuff like convert videos to GIF and emit that. (Assuming there's some way to force mako to render binary data). The other thing I'm wondering, should there be a way to conditionally write the sidecar, even for files that are not skipped. E.g. a flag that says, if your template renders to an empty buffer, skip writing the empty file. That would have to be another boolean option to |
I like the idea of comma separated flags. I'd thought about doing a bit mask but figured that might not be intuitive for some users. The option would still need a fixed number of arguments so if no flags used there would still need to be something like |
Click, which osxphotos uses for option parsing, does not support variable number of arguments to an option. Wondering which of these is better:
or As much as I hate adding yet another option, am leaning towards moving these to |
I'd slightly lean to the latter option as well for simplicity. The one minor downside to that approach is that if you use multiple custom sidecars in a single export you get the same custom flags for each. Unless there's a way to say each |
Unfortunately you'd be stuck with a single set of options and click doesn't provide a way to group options. That's a good point that keeping the options with the sidecar is important (and why I originally included those with --sidecar-template |
In that case I think an explicit |
Any error created by the template should be logged. Add |
Completed in v0.62.0. |
Is your feature request related to a problem? Please describe.
I have a large variety of semi-structured data that I currently embed in the Photos
caption
field as a catch-all. Some of these are tag-like and could be keywords. However, the bulk is either hierarchical or key-value in nature. I'd like to be able to parse and clean this data so that I can map it to more appropriate structure in the XMP export.Describe the solution you'd like
I've been thinking about this for a while and custom sidecar templates via
mako
(like the existing XMP ones) seem like a reasonable approach. This would definitely be an advanced feature and possible footgun. However, I suspect it would be relatively simply to implement, aligns with existing templating functionality, and provides all the flexibility one could need. I could even imagine a repository user-contributed templates to handle specific quirks of all the various photo apps out there.Describe alternatives you've considered
I've considered re-writing the exported XMP/JSON sidecar files post-export. However, I worry about that not playing nice with
--update
.There's also properties like the photo UUID which aren't available. I currently work-around this by including the UUID in the file name. However, I'd like to avoid this because it makes the names annoyingly long.
The text was updated successfully, but these errors were encountered: