+1 to the plugin -> core dependency. But I can't see ever needing a core -> plugin dependency.
Doing so would introduce conflicts when it comes to some dependence resolution, like when pulpcore-plugins v0.1.a1 depends on pulpcore v3.0 pulpcore v3.0 depends on pulpcore-plugins v1.0 @bmbouter yeah pulpcore.plugin is where I'm thinking it should be installed. On Thu, Jun 1, 2017 at 3:09 PM, Michael Hrivnak <[email protected]> wrote: > I think I brought up this idea rather off-the-cuff in a meeting some weeks > ago, but we never had more formal discussion, so thanks for bringing it > back up! I do think this is a good approach for us to explicitly > communicate the version of our plugin API. > > That said, it is a slightly different use case from a normal python > package, and it's worth just thinking through and acknowledging that. The > interesting part is that both the core and the plugin API packages will be > useless without the other. The core is no good to anyone without plugins. > And the plugin API obviously can't be used without the core. That's often a > sign that two things should be distributed together, but we have one extra > and separate reason to package them independently: we want their versions > to move independently. I think that's reason enough for separate packages. > > In terms of package dependencies, maybe we should start with the plugin > package depending on core, but not the other way around. The core won't > care what version the plugin API is at, but the plugin API will definitely > care what version the core is at. If we later find a reason to make the > core package directly depend on the plugin API, it's easy to add. > > 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 >> >> > > > -- > > Michael Hrivnak > > Principal Software Engineer, RHCE > > Red Hat > > _______________________________________________ > 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
