One consideration is that whatever we do for Pulp 2, we’ll have to do again in Pulp 3. For that reason, as ugly as it is, I am leaning toward calling to Fus via a pipe. It seems the easiest, least amount of work, and most reusable.
David On Wed, Oct 10, 2018 at 10:00 AM Milan Kovacik <mkova...@redhat.com> wrote: > ...that might be the question we should ask ourselves once again when it > comes to recursive copying of units between repositories. > > I'd like to poll folks opinions about the possibilities that we may have > when it comes to integrating third party solvers in Pulp. My yesterday's > chat with the #fedora-modularity folks about us integrating the Fus[1] > solver in order to reuse the Fus algorithm ran into a couple of bumps: > > * it would be laborous to create a programmatic Python API between Fus and > Pulp because we can't directly use the libsolv thingies (pools, solvables > and friends) in such an API because Fus is written utilizing GObject, which > is incompatible with Swig, which in turn is used in libsolv to expose the > python bindings. One would have to either re-wrap libsolv code in Fus to > work with pygobject or submit PRs against libsolv to support GObject > introspection. I dunno the details of either approach (yet) but from the > sad faces on the IRC and the Fus PR[1] it seemed like a lot of work but > it's still an option > > * we still should be able to integrate thru a pipe into Fus, that would > make it possible to dump modular and ursine metadata into Fus to perform > the dependency solving in a separate subprocess. We should probably > re-check the reasons behind our previous decision not to do the same with > DNF[2]. > > * we should be able to extend current libsolv solver in Pulp, > reimplementing the algorithm from Fus. This might be as laborous as the > first option. It would probably give us more flexibility as well as more > room for screwing things up but the responsibility would be ours alone. > > Please let me know what option seems more appealing to you; other option > suggestion are welcome too. > > Cheers, > milan > > [1] https://github.com/fedora-modularity/fus/pull/46 > [2] https://pulp.plan.io/issues/3528#note-7 > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
