Hi, > Saku Laesvuori <[email protected]> skribis: > >> Is there a reason why our importers do not use their ecosystem's native >> packaging software libraries? For example, I just spent a good while >> updating and fixing our Haskell importers and while they do now seem >> quite reliable there are still some quirks in the custom parser. The >> Cabal package description format is implementation defined and full of >> compatibility switches, so I would expect it to be much easier to >> implement and maintain a Haskell program that uses the Cabal library to >> parse package descriptions into s-expressions for the rest of the >> importer. > > Basically we choose to write our code in Scheme, it’s the lingua franca > of the project. > > For Cabal, it does lead to extra work, as you write, but overall I think > it’s been beneficial since it allows us to have common infrastructure > and a single interface for all the packages we’re dealing with.
To build on this a bit, from a maintainability perspective, I would be extremely concerned about introducing a bunch of languages to the codebase. If an importer breaks, right now you don't necessarily need to know any language except Scheme to fix it; if each importer is written in a different language, suddenly you need to know that specific language. So the pool of people able to work on that component becomes smaller and consequently it is more poorly maintained. See, for example, how comparatively little work gets done on the Guix daemon, which is written in C++. A ton of people involved with this project know Scheme well enough to feel confident writing packages, working on infrastructure, etc., but relatively few of us feel empowered to write C++.
When dealing with a large codebase with an ever-changing contributor pool like Guix, one of the first questions about any change, and especially any large change, should be, "How does this impact the ability of someone I've never met to work with this code long after I'm gone from the project?"
Best, juli
