Thanks David! On Wed, Oct 10, 2018 at 4:59 PM David Davis <davidda...@redhat.com> wrote:
> 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. > Is your concern the amount of work/code the other approaches might require porting from Pulp2 to Pulp3? I'd say the solver (wrapper) itself should be Pulp-agnostic up to the feed, the model we use. Cheers, milan > > 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
