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 _______________________________________________ Pulp-list mailing list Pulp-list@redhat.com https://www.redhat.com/mailman/listinfo/pulp-list
