Exposing new things to the plugin API?

Development
#1

So I need to build my own APT specific version of https://github.com/pulp/pulpcore/blob/main/pulpcore/plugin/repo_version_utils.py#L16 within pulp_deb.
This method makes use of the helper function here: https://github.com/pulp/pulpcore/blob/main/pulpcore/app/util.py#L182

This helper function is not exposed via the plugin API.
Do you recommend I just duplicate this helper function in pulp_deb, or is there some best practice way of handling this?

My understanding is I should not import anything outside of from pulpcore.plugin from pulpcore into pulp_deb, so from pulpcore.app.util import batch_qs is a no-go?

#2

Hey quba42,

The “right” way to gain access to that call is to have it be made available at https://github.com/pulp/pulpcore/blob/main/pulpcore/plugin/util.py#L15 - that’s how we expose functions to plugin-authors. I don’t see anything in batch_qs() that would be dangerous to expose.

This requires a pulpcore issue, and a release. Backporting would prob require some discussion - I think it would be fine, but there’s a case to be made that it shouldn’t be something added in a Z-release.

All of this will, of course, take some time. That utility function is straightforward Django - if you just wanted to duplicate it, I don’t think that would be too terrible, especially if you opened an issue at the same time to get it made public :slight_smile:

1 Like
#3

Thanks for the assessment, I have opened a pulpcore issue here: https://github.com/pulp/pulpcore/issues/4607

I am fine with duplicating the function for any pulp_deb backports, so there is no pressing need to backport the pulpcore change exposing it.

1 Like
#4

So, while continuing to work on my problem, I found an alternate approach to exposing batch_qs that would allow me to reuse even more of the existing pulpcore implementation: https://github.com/pulp/pulpcore/pull/4618

However, this approach is only acceptable, if it is performance neutral, and I am not certain that it is.