<div dir="ltr">This all sounds wonderful.<div> </div><div>Just to clarify the assertion "Don't use entry points for anything else", I assume we will continue to use entry points for pulp-admin to load "extensions" that are provided by plugins.</div><div> </div><div>Michael</div></div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Sep 1, 2016 at 4:55 PM, Sean Myers <<a href="mailto:sean.myers@redhat.com" target="_blank">sean.myers@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This morning we had an ad hoc discussion regarding the naming/namespacing of our django apps in the Pulp platform and its plugins in Pulp 3. While we were there we also talked a little bit about the pulp plugin API namespace, and how we plan to "register" our plugin apps with Django. I'll outline my recollection of the main points here, and elaborate below. This is all from memory (I forgot to take notes...), so please correct anything I've gotten wrong. - All Django apps should be named <package>.app - Rename pulp.platform to pulp.app (pulp.platform is currently the platform django app) - Plugins should also follow this naming scheme - Plugin API should be exposed under pulp.plugin(s). Anything importable from this namespace should be considered part of the versioned plugin API - Use Django's Applications framework (linked below) to initialize plugins - Use python entry points to discover plugin Django apps and add them to INSTALLED_APPS - Don't use entry points for anything else - Do use Django's AppConfig to trigger any needed plugin initialization functionality The details! = All Django apps should be named <package>.app Currently, no plugins have created Django apps for Pulp 3. The platform Django app is 'pulp.platform' itself. For simplicity's sake, the consensus was to call the Django apps "app". It's brief, and at least in the Django context it makes it clear that this is what gets added to Django's INSTALLED_APPS list to make the plugin known to Django. Since pulp.platform currently is the platform Django app, the proposal is to rename pulp.platform to pulp.app. This work is tracked in <a href="https://pulp.plan.io/issues/2226" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/2226</a>, including details about the open PRs we'd like to see closed before renaming pulp.platform. Please update that issue as appropriate if I missed any 3.0-related pull requests that might be affected by the pulp.platform rename. The plugins have not yet been converted, but when Django apps are created in the plugins, they should be similarly named. So, for example, rpm's Django app will be pulp_rpm.app, docker will will be pulp_docker.app, etc. = Plugin API should be exposed under pulp.plugin(s) We touched on a few other topics, including namespacing the entire plugin API under pulp.plugin, so that plugin writers would ideally only ever "from pulp.plugin import what_they_need". pulp.plugin was used interchangeably with pulp.plugins (I prefer the former but don't care). Explicitly exposing this namespace as "the plugin API" (hopefully) makes it easier to manage semantic versioning here. This would mean, for example, importing base models that we want to expose to plugins into a module named like "pulp.plugins.models". In this example, the plugins would therefore *not* import any models from pulp.app.models. This might be infeasible; Brian is taking it into account while working on <a href="https://pulp.plan.io/issues/2181" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/2181</a> = Use Django's Applications framework to initialize plugins Finally, I mentioned my thoughts about how we would use Django's apps framework as the basis for all plugin capability discovery. The gist is that "we'll use it exactly how Django says to use it", as described in their docs: <a href="https://docs.djangoproject.com/en/1.8/ref/applications/" rel="noreferrer" target="_blank">https://docs.djangoproject.com/en/1.8/ref/applications/</a> Specifically applied to pulp, we're most likely going to use entry points to make the installed plugins discoverable as Django apps and get them added to Django's INSTALLED_APPS. From there, my current thinking is that we'll have a specialized AppConfig subclass that plugins will use to uniformly register their required and optional functionality with the Pulp platform. We get some of this "for free", like models discovery, by virtue of using Django, so I'm thinking that this specifically relates to things like making sure the API is made aware of new views that it'll need to expose, tasks get loaded, or any other initialization-time functionality we might want. _______________________________________________ Pulp-dev mailing list <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a> </blockquote></div> </div>