[Rpm-ecosystem] DNF team would like to take over libdnf ownership

Neal Gompa ngompa13 at gmail.com
Mon Oct 30 15:34:42 UTC 2017


On Mon, Oct 30, 2017 at 10:11 AM, Panu Matilainen <pmatilai at redhat.com> wrote:
> On 10/30/2017 03:21 PM, Colin Walters wrote:
>>
>>
>>
>> On Mon, Oct 30, 2017, at 09:15 AM, Neal Gompa wrote:
>>
>>> As much as I like Rust, it's hampered more by LLVM than anything else.
>>> I struggle to see the advantage of writing in Rust. Not to mention
>>> that the learning curve is quite high compared to other languages. I'd
>>> be more likely to suggest D than Rust.
>>
>>
>> While D supports GC-less programming, the whole ecosystem is
>> bifurcated by that (that said this is based on what I've read
>> and I'm not a D expert).  And if we're keeping DNF in Python, then
>> having two GC's in the same process isn't going to work.
>>
>> (Actually, *are* we keeping DNF in Python?)
>
>
> That's what I'm wondering too. If most of the thing is written in language
> X, then why drag the Python elephant in for ... a cli interface?
>
> Don't get me wrong, I like Python a lot, but I'm not sure it's the best
> language for implementing a depsolver, or a frontend to one. And keeping it
> all in one language would also make debugging and developing easier + saner
> and probably faster too because with the multi-language setting you're
> always first writing the thing itself, then bindings for it, and then the
> actual code to use the thing, and then you discover the interface wasn't
> quite what you wanted so back to drawing board. And of course trimming down
> the dependencies also cuts down the footprint on rescue-images, the number
> of the things that can go wrong etc.
>
> /me never understood why we're doing depsolvers in Python

I think the main reason for Python was for extensibility. That said,
if a plugin architecture was available in libdnf, a good chunk of them
can be migrated there.

If DNF itself was rewritten out of Python into another language,
that's going to cause major headaches without a python-dnf API
somewhere. Ansible, dnfdaemon, etc. would just *break*.


-- 
真実はいつも一つ!/ Always, there's only one truth!


More information about the Rpm-ecosystem mailing list