+1 to this idea. It's something we talked about before, but we never actually decided on. This thread I think is just what we needed to do that. Then a plugin like pulp_foo can depend on pulpcore indirectly through pulpcore.plugin with pulp_foo -> pulpcore.plugin -> pulpcore.
The PyPI name of pulpcore-plugin sounds right. That will provide the Python package that installs in: pulpcore.plugin yes? On Thu, Jun 1, 2017 at 2:38 PM, Patrick Creech <[email protected]> wrote: > On Thu, 2017-06-01 at 11:18 -0400, Bihan Zhang wrote: > > I've been documenting the plugin API semver strategy for 3.0 but I've > noticed that the plugins > > were recently moved from plugin/pulp/plugin to platform/pulp/plugin > > > > My understanding was that we would have separate packages for plugin and > platform to enforce the > > separate semantic versioning, instead of just having documentation on > the plugin version supported > > by platform. > > > > I think the correct workflow is for a plugin writer would denote in > their spec file (or setup.py) > > what pulpcore-plugin versions are supported, and on installation the > package manager can pull in > > the correct pulpcore-plugin package with the correct platform dependency. > > > > > > I wanted to check that this was everyone else's understanding too. > > +1 to separating these as packages. Having a package version to depend on > should help enforce the > plugin api version. > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
