Re: Guix and the developer ecosystem

[Julien Lepiller <julien@lepiller.eu>]

Le 5 août 2023 03:49:30 GMT+02:00, Distopico <distopico@riseup.net> a écrit :
>
>On 2023-07-31, "(" <paren@disroot.org> wrote:
>
>> Hi,
>>
>> Distopico <distopico@riseup.net> writes:
>>> In terms of programming languages, I have found almost all the ones I
>>> needed, with the exception of Kotlin.
>>
>> The build sequence for Kotlin is some sort of hellish double
>> nightmare-loop of doooooooooooooom.  As far as I'm aware, this is how
>> the main dependencies of Kotlin relate to each other:
>>
>>                      .---------------------.
>>                      |                     |
>>    .-------------> gradle ------.          V
>>    |                 ^          |        kotlin ------.
>> openjdk              '----------'        ^    ^       |
>>    |                                     |    '-------'
>>    '-------------------------------------'
>>
>> Fun!
>>
>
>Nice graphs, sound pretty complicate to solve that  :/

There's hope, because you can skip building gradle, and manually build kotlin. So you end up with a chain of kotlin versions. I actually managed to build some, but I'm stuck after 1.0.0:

https://framagit.org/tyreunom/guix-android/-/blob/master/android/packages/kotlin.scm

That's already a huge chain, and it's probably missing ten times more…

>
>>> In some languages like Haskell and GoLang, the language server depends a
>>> lot on the version it was compiled with. For example, I tried gopls,
>>> which is available in Guix, but it was built with Go 17 and is not
>>> compatible it.
>>
>> Ah, that'll be because Guix uses Go 17 for building Go programs, unless
>> you override the ``#:go'' keyword, but the latest version of Go it
>> provides is Go 20.  I suppose it couldn't hurt to change it to be built
>> with the latest version.  (We can't just make the default build Go be
>> 20, as that would require the CI to rebuild all Go packages.)
>>
>
>And that can be another problem, or it is indeed a real problem, going
>to a project that uses Go 1.7, but all the tools are built around Go
>1.20. That's why I imagine something like having tools relative to their
>versions, so we can install gopls@0.11 and go@1.17 together because they
>are compatible. And if I switch to another project, I could install
>Go@1.15 and gopls@0.9.5. Currently, that is not possible, at least I
>haven't seen it in Go/Rust/Haskell in Guix.

There's always the time-machine or inferiors. If it worked at some point in Guix, you can go back in time and get those packages. Not ideal since they'll depend on older software, but at least, if it worked in the past, it's guaranteed to continue to work today.

>
>>> I have started contributing to packages that I believe could be useful,
>>> and I like to contributing to teams such as Haskell or Rust. However,
>>> there are other topics, such as compiler and tools compatibility, where
>>> I'm not entirely clear about the direction that has been planned.
>>
>> The problem with Haskell, Rust, and Elm is mainly, as lilyp has
>> said/implied, that while the dependency trees of C applications and such
>> typically resemble the following:
>>
>>         O <-- O
>>   O <-- O <-- O
>>         O <-- O
>>
>> dependency trees for Rust, Haskell, and Elm look like this:
>>
>>                         / O
>>                   / O <-- O
>>                   |     \ O
>>                   |
>>                   |     / O
>>             / O <-- O <-- O
>>             |     |     \ O
>>             |     |
>>             |     |     / O
>>             |     \ O <-- O
>>             |           \ O
>>             |
>>             |           / O
>>             |     / O <-- O
>>             |     |     \ O
>>             |     |
>>             |     |     / O
>>   O <-- O <-- O <-- O <-- O
>>             |     |     \ O
>>             |     |
>>             |     |     / O
>>             |     \ O <-- O
>>             |           \ O
>>             |
>>             |           / O
>>             |     / O <-- O
>>             |     |     \ O
>>             |     |
>>             |     |     / O
>>             \ O <-- O <-- O
>>                   |     \ O
>>                   |
>>                   |     / O
>>                   \ O <-- O
>>                         \ O
>>
>> Except in reality it's much much much much much worse.
>>
>> So it's not because that's not something we'd like to have, it's largely
>> because packaging such things is a royal pain and there aren't all that
>> many people with the motivation to do that.
>>
>
>
>And this is the current reality, and it will become more and more
>common, whether for better or for worse. Package managers make it so
>convenient to install dependencies, but it leads to an abuse in that
>regard. I could name many of the most widely used programming languages
>today that have the same problem: JavaScript, Python, Haskell, Rust,
>just to name a few. So, here is my question: Is there a future vision
>for this situation? Because it will become more and more common over
>time.

The solution to this issue could be better importers. The package managers of these languages manage to build the packages, so there's no reason we shouldn't be able to do so too. There are a few good importers, but others need to be written or polished to make them more reliable and useful.

Another approach could be to integrate guix in these tools. Maybe it would be good advertisement and incentivize developpers to make their package work well in guix. Imagine "pip export --guix some packages > guix.scm" or similar :)

On a more sociological point of view, we should raise these concerns to package managers and developpers to try and find a more satisfying solution.