[Pulp-dev] pulp-owned pypi packages that pulp did not author
dalley at redhat.com
Tue Jul 14 15:21:39 UTC 2020
> Thanks Daniel,
> I've reposted to pulp-dev, so you might want to re-post your reply
> there too, but:
> Great, if createrepo and libcomps is just "intermediate" while we
> actively (try) to help upstream get there, I can totally take that.
> For solv: well, if they don't want it there, IMHO we should not
> publish it under their name either?
It's not so much that they didn't want it there; more that they don't care
about that use case at all and it's not something that they want to
maintain or think about. Similar to the situation with createrepo_c except
that there was less hope that they would eventually take back control :)
The primary reason is just that we wanted it to be possible to run the RPM
plugin on Debian-based distros, and relying on any RPMs would go counter to
that goal. But there were some other motivations also - at the time, the
Python community was deciding on which technology to use for the new
dependency resolver in Pip, and libsolv was mentioned as a candidate (but
ultimately decided against for various reasons). One of the reasons was
that nobody had ever made a Python package for libsolv and they weren't
even sure if it was possible - and I found this discussion at the same time
as I was already wanting to package it anyway for Pulp.
On Tue, Jul 14, 2020 at 9:47 AM Daniel Alley <dalley at redhat.com> wrote:
> My apologies! s/Evengi/Evgeni, the letters got swapped in my brain : /
> On Tue, Jul 14, 2020 at 9:37 AM Daniel Alley <dalley at redhat.com> wrote:
>> Reposting my response from the other thread:
>> Hi Evengi,
>> In the case of createrepo_c and libsolv, the upstream merged all of the
>> build script changes that were necessary to enable producing Python
>> packages, so in that sense the packages we are producing are completely
>> unmodified. However, the RPM team isn't particularly interested in
>> maintaining Python packages, and so they gave us permission to maintain the
>> packages ourselves. I've forgotten in what medium that discussion took
>> place so I'm not sure where even to look for a record of it. Nonetheless I
>> actually have a PR open against both projects which would automate the
>> entire packaging and release process for Python packages with Github
>> Actions, so that they could become the official owners/maintainers without
>> actually needing to do any work (hopefully).
>> However you may notice that those PRs have been sitting for a while :)
>> In any case we'd definitely love to transfer ownership back to them, and
>> I've been trying to facilitate that process a little bit (with the PRs) but
>> I don't really want to push on them too hard to do so.
>> With respect to libsolv it's a little more complicated. As far as I can
>> tell the upstream is just not interested at all and would probably not
>> accept the changes into upstream regardless of whether we made the release
>> process automated. I asked multiple times if they were interested and got
>> essentially no response.
>> + some discussion on IRC
>> Feb 24 10:14:47 <dalley> hello Igor, do you have any opinion on this?
>>> Feb 24 10:18:24 <ignatenkobrain> Well, I don't see any reason to publish
>>> libsolv to pypi :)
>> On Tue, Jul 14, 2020 at 9:31 AM Evgeni Golov <evgeni at redhat.com> wrote:
>>> Hi pulp-dev,
>>> While packaging pulp3 (more precisely pulp-rpm), I stumbled over the
>>> fact that the "pulp" pypi user has uploaded "solv", "libcomps" and
>>> "createrepo-c" without being the real author. To make matters worse,
>>> the uploads don't 100% represent the original artifacts released by
>>> the respective upstreams as they don't release python packages but
>>> classic tarballs. In the case of "solv" this lead to an interesting
>>> bug: solv upstream does not build a python egg, but your package did,
>>> and then as the pulp-rpm egg has "solv" as a dependency, it won't load on
>>> a system that uses the "real solv" without the egg. We patched that
>>> out in packaging, but it remains ugly.
>>> I kinda understand why Pulp did that, this way you can rely on "pip"
>>> to install everything for a working pulp-rpm environment, but I think
>>> we/you shouldn't do that and instead either persuade (and help!) the real
>>> upstreams to publish their stuff to PyPI or bite the bullet and accept
>>> that pip is not able to install everything needed for a working
>>> Beste Grüße/Kind regards,
>>> Evgeni Golov
>>> Senior Software Engineer
>>> Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
>>> Handelsregister: Amtsgericht München, HRB 153243,
>>> Geschäftsführer: Charles Cachera, Laurie Krebs, Michael O'Neill, Thomas
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev