Previously, we had two places where we were passing kwargs that affected
the image generation: the ImageSpec constructor and the generate method.
These were essentially partial applications. With this commit, there's
only one partial application (when the spec is instantiated), and the
generate method is called without arguments. Therefore, specs can now
be treated as generic generators whose constructors just happen to
accept a source_file.
The registry module splits the work that specs.SpecRegistry
used to do into two classes: GeneratorRegistry and
SourceGroupRegistry. These two registries are wrapped in
Register and Unregister utilities for API convenience.
As mentioned in #167, we want to be forward thinking and allow for a
hypothetical spec supertype which has the same functionality as an image
spec but doesn't require a source file: a generator. To this end, I've
renamed `ImageSpec.apply()` to `ImageSpec.generate()` and extracted
a `GeneratedImageCacheFile` base class from `ImageSpecCacheFile`, which
supports the more general interface of a generator--namely, a
`generate()` method with arbitrary args and kwargs.
The registry's `get_spec()` was already supporting kwargs as a means to
provide information about the source to the spec constructor/factory
function, but the ``SpecHost`` class wasn't capable of accepting any.
This commit rectifies that. The main goal purpose of this is to allow a
bound field (the file attached by ``ImageSpecFileDescriptor``)--and the
attached model instance--to be taken into account during the spec
instance creation.
Related: #156
This allows any file object to be used--even those that don't have a
`field` attribute. For example, you could theoretically use one spec
field as a source for another.
