On Mon, Oct 30, 2017 at 10:11 AM, Panu Matilainen <[email protected]> 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! _______________________________________________ Rpm-ecosystem mailing list [email protected] http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
