Saku Laesvuori <[email protected]> writes: >> >> 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. > > I agree with most of this, but that "you don't need to know any > language > except scheme to fix it" holds only for a rather limited set of bugs, > at > least in the case of Cabal. Much of the time required to write the > fixes > in #9933[1] (reviews appreciated) I spent on deciphering the correct > syntax from Cabal's Haskell source code. This would never have been > needed if the importer offloaded the parsing to that very same code > via > a Haskell program.
This will result in different importers being available on different architectures. For instance, GHC can only work on x86 64, and we don't have GHC for other architectures. Moreover, if one needs to test the importer, additional dependencies will need to be added to the Guix package. > > Now the importer seems to work well enough, but robustness to upstream > change, in addition to simplicity and deduplication of code, was what > made me think about this. I would expect that to also help with > maintainability in some sense. > > [1]: https://codeberg.org/guix/guix/pulls/9933 > > - Saku
signature.asc
Description: PGP signature
