PySequence + HashIO Integration for Sequence Hashing

[patrickwolf]

Depends on: Ticket #19 (HashIO handles .hash file and glob hashing)

Feature
Expose HashIO-based sequence hashing inside PySequence, allowing unified sequence tracking and verification.

Proposal for PySeq

1. Generate

   • generate_hash(path) → returns combined hash of sequence
   • generate_hash_file(path) → writes .hash file using HashIO with the sequence

2. Verify

   • verify_sequence(path, hash_value) → compares against expected hash
   • verify_sequence(path, hash_file) → compares against .hash file contents
   • (the .hash file can be found automatically from the sequence name ie seq.%4d.exr -> seq.hash or seq.0000.hash)

3. CLI Extension

   • Add hash/verify commands to existing PySequence CLI
   • Optional: fallback if HashIO not installed

Why It’s Unique

• PySequence becomes the first file sequence tool with built-in hash-based change detection
• Enables one-line DB tracking (e.g., seq: shot001.%04d.exr, hash: abc123)
• Perfect for backup verification, version validation, and vendor ingest checks
• I can instantiate and verify a pyseq from a single string "shot001.%04d.exr|1000-1001|4540938fsdf"

[rsgalloway]

not sure if this is a feature request for hashio or pyseq.. .

either way, this should be easily doable. it sounds like it's mostly just a convenience function to wrap up hashing sequences plus some naming conventions.

[patrickwolf]

It's a feature request for pyseq but it connects with #19 so I posted it here..

And yes most of the things are there I just felt when it's all brought together into a fun and easy package that it's pretty cool that a seq can have a hash/ hash file and can be verified and it's extra fast if it's already cached etc..

Ie the utility goes up when it all comes together

A bit like the iPod bringing MP3 players into a new package 😊

[rsgalloway]

ok, sounds like maybe the real ask for #19 is a) supporting wildcards from the CLI, and b) generating checksums for a group of files or folders, and this one #20 is about integrating into pyseq, possibly with a new CLI tool, shash, or similar. if that's the case I will add notes to #19, and move this one to pyseq.

edit: on second thought I am not clear on the value of a combined checksum for a sequence or a folder vs per-file checksums. yes, a combined checksum will tell you if any of the files have changed, but per-file checksums will tell you which files.

[patrickwolf]

on second thought I am not clear on the value of a combined checksum for a sequence or a folder vs per-file checksums. yes, a combined checksum will tell you if any of the files have changed, but per-file checksums will tell you which files.

i'm only storing the seq.%4d.exr name in shotgun and i would like to store the combined checksum with it.. that's one very useful use case at least for pipeline ie adding a checksum column to the published file entity

is a) supporting wildcards from the CLI, and b) generating checksums for a group of files or folders, and this one
from the cli and from code

is about integrating into pyseq, possibly with a new CLI tool, shash, or similar

CLI and code yes... and it could just be part of the existing tools that output the sequences found via a flag ie lss --hashio

[rsgalloway]

i'm only storing the seq.%4d.exr name in shotgun and i would like to store the combined checksum with it.. that's one very useful use case at least for pipeline ie adding a checksum column to the published file entity

why not store the checksum in a separate field?

storing the compressed sequence string in sg_path_to_frames is common practice, but overloading that with extra data would break the rv playback feature, etc.

[patrickwolf]

ie adding a checksum column to the published file entity

just a misunderstanding :) hash would be a separate column. i agree it doesn't make sense to combine them in one field