Pulp

Having pulpcore-plugin and pulpcore in separate repos brings many challenges (see below), and a few benefits. Let's make things much simpler by deleting the pulpcore-plugin repository and moving all code to pulp/pulpcore repository.

Challenges motivating the change¶

• Releasing two things makes releasing twice as long and difficult. This has been a practical issue recently.
• Many (majority?) of the objects in pulpcore-plugin import from pulpcore itself, so when you make changes to pulpcore you have to do extra work to add the changelog for plugin writers to pulpcore-plugin. Merging these together would let you make 1 PR.
• It forces us to have two documentation sites. Not only is this extra work for us, but it makes our actual plugin docs difficult to find.
• Coordinating "Required PR:" checkouts is a bunch of extra work (for the CI maintainers).

Why did we originally do it?¶

There are a few reasons I remember:

1. It clearly marked which APIs are governed by the plugin API. You can be sure you're plugin is OK as long as you always import from pulpcore.plugin.

2. We could version the Plugin API at < 1.0 so that we could modify things in a backwards incompatible way in the Y stream still as long as < 1.0.

3. it allowed us to release pulpcore-plugin separately. (This didn't work in practice though because so many objects from pulpcore-plugin are imported from pulpcore, you can't release them separately...)

Of all of these (1) is the most important.

The plan¶

Move all code from pulpcore-plugin to pulpcore. Have the version of pulpcore-plugin still declare 0.1.0, but remove it's setup.py since it won't be a separately installable package. Merge the test dependencies, dependencies, and docs.

We should port the changelog and have the pulpcore package report on the pulpcore.plugin changelog also.

Plugins will then delcare dependency on pulpcore directly. Overall this will make Pulp simpler for everyone.

We'll still have pulpcore.plugin, it'll just be in the github.com/pulp/pulpcore repo. This allows us to still clearly mark exactly what is included in the plugin API (benefit 1).

We can document in the plugin_api docs that the 3.Y versions of the plugin API may change backwards incompatibly so plugins should declare compatability only with the current 3.Y release until it's stable. (This achieves benefit 2).