Thanks David!
On Wed, Oct 10, 2018 at 4:59 PM David Davis 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
> 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
