unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Julien Lepiller <julien@lepiller.eu>
To: guix-devel@gnu.org, Distopico <distopico@riseup.net>,
	"(" <paren@disroot.org>
Subject: Re: Guix and the developer ecosystem
Date: Sat, 05 Aug 2023 08:10:22 +0200	[thread overview]
Message-ID: <0375EB88-2297-48B2-B80F-A31DB7170245@lepiller.eu> (raw)
In-Reply-To: <87h6pemep8.fsf@riseup.net>



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.


  reply	other threads:[~2023-08-05  6:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-27  0:29 Guix and the developer ecosystem Distopico
2023-07-29 19:48 ` Liliana Marie Prikler
2023-08-05  1:11   ` Distopico
2023-08-05 17:29     ` Liliana Marie Prikler
2023-08-05 19:48       ` (
2023-08-05 20:12         ` Liliana Marie Prikler
2023-08-08 16:59     ` Saku Laesvuori
2023-07-31  9:42 ` (
2023-08-05  1:49   ` Distopico
2023-08-05  6:10     ` Julien Lepiller [this message]
2023-07-31 18:55 ` Wilko Meyer
2023-08-05  1:40   ` Distopico
2023-08-16 14:22 ` Ludovic Courtès
2023-08-18 17:16   ` Distopico
2023-08-24 15:01     ` Ludovic Courtès
2023-08-29 18:42       ` Distopico
2023-08-19  8:29 ` Simon Tournier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0375EB88-2297-48B2-B80F-A31DB7170245@lepiller.eu \
    --to=julien@lepiller.eu \
    --cc=distopico@riseup.net \
    --cc=guix-devel@gnu.org \
    --cc=paren@disroot.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).