Hopper Constants

Named capture groups (NCGs) creates properties that can be tested and used in path formatting. As of version 0.1.1, they can be persisted for rebuilding stores.

However NCGs are not complete replacements for source_name, source_stem, and source_path because some times a value can not be extracted from a path. But rather the path's location implies something about the files placed into it.

Hopper constants fills this gap by allowing a hopper to bind whatever value it wants to a property.

[hopper]
%NAME = value

Example

The following configuration ingests images in two ways, as single pictures or as part of a zip file.

• The former is expected to be loose pictures
• The later is expected to be pages of a book

[hopper]
path = /home/user/download
include = file_name /(?<name>.+?)\.(?:jpe?g|gif|a?png|bmp)$/i
store = pictures
%kind = picture
save = title
save = kind

[hopper]
path = /home/user/download
include = file_stem /(?<title>.+?)(?:\s*\((?:.+?)\))?$/i
include = file_extension zip
transform = unzip
store = books
%kind = page
save = title
save = kind

Here's the relevant store configs

[store]
name = pictures
include = %kind picture
include = file_extension /^(?:jpe?g|gif|a?png|bmp)$/i
path = /home/user/pictures/{group_id}-{index}.{file_extension}

[store]
name = books
include = %kind page
include = file_extension /^(?:jpe?g|gif|a?png|bmp)$/i
path = /home/user/books/{title}/{index}.{file_extension}

During normal ingestion files will be correctly routed to both without the need to define the kind attribute.

However, this becomes useful when the stores must be rebuilt. At which point the kind and title values will be available for filtering and path formatting. Which in this case allows one to offer their entire collection to a store and it will decide which actually contains the right "kind" of content it wants in its directory structure