[Pulp-list] Blog - Preview: Creating a Pulp Plugin

[Jay Dobies]

> That generally looks like a good fit with what we want to do in
> PulpDist, but I'm not sold on the idea of actually having to import and
> run Python code in order to get at the importer and distributor
> metadata, nor on the requirement to install (or symlink) Python code
> into a /var subdirectory to get the plugins to work.
>
> Rather than a dedicated directory for the actual plugin code, have you
> considered a JSON based configuration model along the following lines
> (closer to the existing interface for the content type definitions):
>
> {"importers": [
> {
> "id" : "sync-tree",
> "display_name" : "Directory tree importer",
> "types" : ["file"],
> "plugin" : "pulpdist.pulp_plugins.TreeImporter"
> },
> {
> "id" : "sync-versioned-tree",
> "display_name" : "Directory tree importer (multiple independently
> updated versions)",
> "types" : ["file"],
> "plugin" : "pulpdist.pulp_plugins.VersionedTreeImporter"
> },
> {
> "id" : "sync-snapshot-tree",
> "display_name" : "Directory tree importer (sequentially released
> versions)",
> "types" : ["file"],
> "plugin" : "pulpdist.pulp_plugins.SnapshotTreeImporter"
> },
> {
> "id" : "sync-snapshot-delta",
> "display_name" : "Rsync delta generator (sequentially released versions)",
> "types" : ["rsync-delta"],
> "plugin" : "pulpdist.pulp_plugins.SnapshotDeltaImporter"
> },
> {
> "id" : "sync-delta-tree",
> "display_name" : "Directory tree importer (sequentially released
> versions based on rsync delta files)",
> "types" : ["file"],
> "plugin" : "pulpdist.pulp_plugins.DeltaTreeImporter"
> }
> ]}
>
> And then in a separate file in the distributors directory:
>
> {"distributors": [
> {
> "id" : "publish-delta",
> "display_name" : "Rsync delta publisher",
> "types" : ["rsync-delta"],
> "plugin" : "pulpdist.pulp_plugins.DeltaDistributor"
> }
> ]}
>
> The key changes would be to move the metadata out into static JSON
> files, and then include a "plugin" field in the metadata that tells Pulp
> where to find the actual Python class implementing the plugin. That way,
> all the restrictions on naming and file locations for plugins can go
> away (aside from the usual Python namespace rules) and the deployment
> model becomes simply:
>
> - install your Python package (including any Pulp plugins)
> - add JSON for new content types to /v/l/p/plugins/types
> - add JSON for new importers to /v/l/p/plugins/importers
> - add JSON for new distributors to /v/l/p/plugins/distributors
>
> Cheers,
> Nick.

It's an interesting approach and I like it. I come from more of a Java 
background where the strategy typically boils down to "drop a JAR 
somewhere and it works". So I tend not to think in terms of using 
site-packages for installed content and usually assume a plugin 
framework takes on that responsibility.

The metadata method originally bothered me, but in the end I'm not a 
huge fan of JSON so the less I had to dork with it, the better. But 
given this proposal of centralizing on the plugin descriptor instead of 
dropping it into a directory, it makes more sense.

These comments seem to be more stylistic than issues with the current 
approach not working. For now, I'd like to stick with the current 
approach simply because it's already there and working. Spare time to 
implement/test a new model isn't there right now but in a few sprints 
when we've gotten a bit more feedback from people I could see pushing to 
get sprint time to readdress this (at that point, the actual plugin code 
wouldn't have to change so migrating existing plugins wouldn't be bad -- 
it probably wouldn't be tough to support both models either).

Thanks for the feedback, it's neat to these sorts of alternatives.

-- 
Jay Dobies
RHCE# 805008743336126
Freenode: jdob @ #pulp
http://pulpproject.org | http://blog.pulpproject.org