From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id EHWeIjvozWTyQQAASxT56A (envelope-from ) for ; Sat, 05 Aug 2023 08:12:11 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id EHF1IjvozWT6iQAAauVa8A (envelope-from ) for ; Sat, 05 Aug 2023 08:12:11 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 40C8443519 for ; Sat, 5 Aug 2023 08:12:11 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=lepiller.eu header.s=dkim header.b=Ydf1pNDg; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=lepiller.eu ARC-Seal: i=1; s=key1; d=yhetil.org; t=1691215931; a=rsa-sha256; cv=none; b=ZoyNVNCsxHWorxu958A1jDS2S2E41glxj5EjQxczX9aCPKU5Yl47lYC/tuFHursV2247ep aAOj/yR2ba8xWLUu3+TeyorYV9HT/e1j6hIZlHGG/kcKNbO3xvbtEe2Zijs6C/xtpHTGBI 0+1ngekARgJSx5RtrDVTk81vA2k8qMDhVcSbVHkh7LdMsaGZV2XUMiJ5xmuyaSa5Q8EWy/ ozd91Xjhf2AzD30+Q5KDjfpzmBvo26UXmRmc+3vL/va9Bm9dYzBm787olP2EqhjW5AgnS4 ekUEP5ZzYIc+hD+G2q6PZV9FNGyah+aWrOU+Zvi5V2UFSgKvvqRazzniS1CWpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1691215931; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=1fhTxYrJoFL6QO7p8Ci/OP+bL52wOM/XjEh/JYgPh/8=; b=uwlraPXZJeVz7O1t4MSwIUtbc1dJckaW0fxdIZip18y6hYOT/PUnyC7mJ79AiaxXJOPfXC UgqpajTyBQUuYbuXn2Wjyfas0/9ols1aq92S6Mzfxii1D5OpMttazzkcRyB/cGTewNlKFO fTp/dypxfEXBuchvS2tVPuVIS+AKYZFb2RBK2N8b2EZkrOAkpN1WeEeOuQ6qr05C+3O/y7 7ezSjv1eNbRuhHyS3ahm1Kcb20GlumbGEF89RKaA7X7rnD9pP2JFy29oWjp6Sh3PukOkHy fmokZb3/RfGPcHo+AHs70NVyDBLWxZCSdU3OWoQ/qPyPg14jeFiD5LqVwlt9EA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=lepiller.eu header.s=dkim header.b=Ydf1pNDg; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=lepiller.eu Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qSAVn-0004Rx-UI; Sat, 05 Aug 2023 02:11:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSAVl-0004Rk-RI for guix-devel@gnu.org; Sat, 05 Aug 2023 02:11:37 -0400 Received: from lepiller.eu ([89.234.186.109]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSAVj-0003s7-5Q for guix-devel@gnu.org; Sat, 05 Aug 2023 02:11:37 -0400 Received: from lepiller.eu (localhost [127.0.0.1]) by lepiller.eu (OpenSMTPD) with ESMTP id 887e098a; Sat, 5 Aug 2023 06:10:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=lepiller.eu; h=date:from :to:subject:in-reply-to:references:message-id:mime-version :content-type:content-transfer-encoding; s=dkim; bh=Ul3l5N/AkIu/ cwvWbU7j4IYs4FOEW/2QzXPUd/DrUdg=; b=Ydf1pNDgZkhWhrJtnRSi1ssVF09f LX0QAz0FsJeyrXRrKWdMDKZO0gjGeGMf7K1hk29ktNlZKhzdTbDMj4FQh3J01u+x mCnUbQxb/+ValTLu8CWtBO+RMvWdDVXW56a5ysWmidXthk3thOiQvtoxBT4Izymx LySeioiZdCRaYTSdLqt56Knw+a6Jk45NKdCXkaZyi9rI3s2tk7f4kYEWIO6eHZ7o 08iZs8XgYpMwdlIGqxHIZXl0A6driLpyFDMULtKa9FlKwRTSqA4YaWpWoziHYBAH p9fiv2N1CnTBaFwnJLGR6SNtd3sgNrJdsWfxdGofQmQA+Y2EELLmerwFfQ== Received: by lepiller.eu (OpenSMTPD) with ESMTPSA id ef21c8bb (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 5 Aug 2023 06:10:25 +0000 (UTC) Date: Sat, 05 Aug 2023 08:10:22 +0200 From: Julien Lepiller To: guix-devel@gnu.org, Distopico , "(" Subject: Re: Guix and the developer ecosystem User-Agent: K-9 Mail for Android In-Reply-To: <87h6pemep8.fsf@riseup.net> References: <875y662lmg.fsf@riseup.net> <874jlk2yeq.fsf@disroot.org> <87h6pemep8.fsf@riseup.net> Message-ID: <0375EB88-2297-48B2-B80F-A31DB7170245@lepiller.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=89.234.186.109; envelope-from=julien@lepiller.eu; helo=lepiller.eu X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -9.64 X-Migadu-Scanner: mx2.migadu.com X-Migadu-Queue-Id: 40C8443519 X-Spam-Score: -9.64 X-TUID: nl2b+2s6IajO Le 5 ao=C3=BBt 2023 03:49:30 GMT+02:00, Distopico = a =C3=A9crit=C2=A0: > >On 2023-07-31, "(" wrote: > >> Hi, >> >> Distopico writes: >>> In terms of programming languages, I have found almost all the ones I >>> needed, with the exception of Kotlin=2E >> >> The build sequence for Kotlin is some sort of hellish double >> nightmare-loop of doooooooooooooom=2E As far as I'm aware, this is how >> the main dependencies of Kotlin relate to each other: >> >> =2E---------------------=2E >> | | >> =2E-------------> gradle ------=2E V >> | ^ | kotlin ------=2E >> openjdk '----------' ^ ^ | >> | | '-------' >> '-------------------------------------' >> >> Fun! >> > >Nice graphs, sound pretty complicate to solve that :/ There's hope, because you can skip building gradle, and manually build kot= lin=2E So you end up with a chain of kotlin versions=2E I actually managed = to build some, but I'm stuck after 1=2E0=2E0: https://framagit=2Eorg/tyreunom/guix-android/-/blob/master/android/package= s/kotlin=2Escm That's already a huge chain, and it's probably missing ten times more=E2= =80=A6 > >>> In some languages like Haskell and GoLang, the language server depends= a >>> lot on the version it was compiled with=2E For example, I tried gopls, >>> which is available in Guix, but it was built with Go 17 and is not >>> compatible it=2E >> >> 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=2E I suppose it couldn't hurt to change it to be bui= lt >> with the latest version=2E (We can't just make the default build Go be >> 20, as that would require the CI to rebuild all Go packages=2E) >> > >And that can be another problem, or it is indeed a real problem, going >to a project that uses Go 1=2E7, but all the tools are built around Go >1=2E20=2E That's why I imagine something like having tools relative to th= eir >versions, so we can install gopls@0=2E11 and go@1=2E17 together because t= hey >are compatible=2E And if I switch to another project, I could install >Go@1=2E15 and gopls@0=2E9=2E5=2E Currently, that is not possible, at leas= t I >haven't seen it in Go/Rust/Haskell in Guix=2E There's always the time-machine or inferiors=2E If it worked at some point= in Guix, you can go back in time and get those packages=2E 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=2E > >>> I have started contributing to packages that I believe could be useful= , >>> and I like to contributing to teams such as Haskell or Rust=2E However= , >>> there are other topics, such as compiler and tools compatibility, wher= e >>> I'm not entirely clear about the direction that has been planned=2E >> >> The problem with Haskell, Rust, and Elm is mainly, as lilyp has >> said/implied, that while the dependency trees of C applications and suc= h >> 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=2E >> >> So it's not because that's not something we'd like to have, it's largel= y >> because packaging such things is a royal pain and there aren't all that >> many people with the motivation to do that=2E >> > > >And this is the current reality, and it will become more and more >common, whether for better or for worse=2E Package managers make it so >convenient to install dependencies, but it leads to an abuse in that >regard=2E 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=2E So, here is my question: Is there a future vision >for this situation? Because it will become more and more common over >time=2E The solution to this issue could be better importers=2E The package manage= rs of these languages manage to build the packages, so there's no reason we= shouldn't be able to do so too=2E There are a few good importers, but othe= rs need to be written or polished to make them more reliable and useful=2E Another approach could be to integrate guix in these tools=2E Maybe it wou= ld be good advertisement and incentivize developpers to make their package = work well in guix=2E Imagine "pip export --guix some packages > guix=2Escm"= or similar :) On a more sociological point of view, we should raise these concerns to pa= ckage managers and developpers to try and find a more satisfying solution= =2E