My comment was about the <<I've never understood why some shy away from "number of dependencies" per-se for C projects>> part, not Guile itself although it also

My comment was about the <<I've never understood why some shy away from "number of dependencies" per-se for C projects>> part, not Guile itself although it also applies to what you wrote, specifically this: > they're not in the position of maintaining guile, they're a 3rd party user who'd be packaging it and its dependencies up for use in their own application. ...as it doesn't matter if they are using these other dependencies directly or indirectly, they are still dependencies of their application - if anything these are dependencies they didn't have any say over (they had say over depending on their direct dependency - like Guile - but not on their dependency's own dependencies which were decided by the programmers of that dependency) so they have less knowledge on how those are used and why they are used (knowledge they may need to gain in the case where something goes bad as i wrote above). Basically the more dependencies you have (not necessarily the number of libraries you depend on but also how much of each library you are using), the more people you invite to have a say in how your project will work and as such the more likely to encounter friction and misaligned goals. This is why a lot of C programmers prefer to use small single-purpose libraries (to the point where "single header libraries" have taken off significantly) and avoid huge "multitool" frameworks. > its own home-grown code instead of using something like GResolver, which wouldn't have had that issue. Perhaps, but it may have had other issues you (or even the programmer who wrote that code) didn't know about.