From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id cAejCCCHzmRoWgEASxT56A (envelope-from ) for ; Sat, 05 Aug 2023 19:30:08 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id IL38ByCHzmSrJAAAG6o9tA (envelope-from ) for ; Sat, 05 Aug 2023 19:30:08 +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 7BD4F4D8FA for ; Sat, 5 Aug 2023 19:30:07 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=mO0bZxQX; 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=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1691256608; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=dsj/nDGNDm343k0xaHQSftvCYtAt3sTHVmXYqzdcoBA=; b=N+EaZ6gXGXMUWQhRlcYb1M5vXMOiJMCHmbdcJpetVUYnKOxaprLit1CJNpUhQqfHCxF3Da pxJ+0dketkoDyMNxd1ePMbkBe97XHtzp/7IkkV0XnSIflR46pcYCwCc153MmgYUUvUuA1R MlS5Xo21L3kTp6FlIGw7WGQU0FKYCw6UPx8m1cdRZ9xHQPjX/zM8//NA+7FQyozsktRSc1 b//t6etHEbekLn0gp9mRUJ59SOWe1ceOGp7uhu0p+5nxmoYfFYUKnQXxXE73HntcgGKlcF k4uNMUArSK/rbYeGxeK+amU3g4VRTiBXOzI2okyt9EoujG6n5ilM2nwfOGxl+A== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1691256608; a=rsa-sha256; cv=none; b=S965P0/m78Y5DUMHrz+AgFXd8QnBFkNQhRK+HGqqqLJv85o9/5XhKqDmtIVaRQ0CUE/R40 Xq/B3ipoL92dOTpuec/7cuoA1AHUTCZ/nxVkHGiGVml0V3e9BeNgGF0OeE31BGWm0HQoMZ 6IEy9uXFAT5yXFc+wj4HFNNFj82Ty0pTHX3qYYq1cqR00zLiDw2AXvsgqHnONyB1OHg1hf OGMHjwHW0SMELIGTZlQqCdMupkXbV1iMdrbjfzjs8sQjbNpesIlqHURmEb9J3wa3N/B18T pSQ30fBXsG4F52EEQ05/h1Iy4j/vHJYnIudJjAnJGULY9NqgDAM5N4JNiyOiSg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=mO0bZxQX; 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=gmail.com Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qSL5q-0003CQ-CJ; Sat, 05 Aug 2023 13:29:34 -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 1qSL5p-0003C2-3F for guix-devel@gnu.org; Sat, 05 Aug 2023 13:29:33 -0400 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qSL5m-0006v1-O7 for guix-devel@gnu.org; Sat, 05 Aug 2023 13:29:32 -0400 Received: by mail-wr1-x444.google.com with SMTP id ffacd0b85a97d-3110ab7110aso2799047f8f.3 for ; Sat, 05 Aug 2023 10:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691256568; x=1691861368; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=dsj/nDGNDm343k0xaHQSftvCYtAt3sTHVmXYqzdcoBA=; b=mO0bZxQXi7fEZsu7Qfsu1M1iq4kiSJL6WBXsw3FDlCgmV4BcKtIAEy5u4FT7PHm+Zp +odfhsvVvGMxPtYU4JQptxam2w+JeRgxAUpcvDyowBfUiAVCU11zCyUz3lx3jrdhT8MK sl87u67YQ7P70aOh6Dx1jGv3/EJNTC0Q/SGLZkjdPOWap3ync5IsxQf3hvz9/2J3355z naatB6jMYgoQRiBUnQrC7Ly9n8TpaX4Ve4pn7fxka/yL5/QH3EHDUQemCU0YoIGU2Wao JMtOBaaJJpJiGb0gcSwNYR3/EkY8ERSRezIIodZ1kPTx11wbxREVimims6bJqIX9bC8P hbIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691256568; x=1691861368; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dsj/nDGNDm343k0xaHQSftvCYtAt3sTHVmXYqzdcoBA=; b=gf0rwwH+Zhk/hmHzyi6bcA/NT7Nn/geumgal95gXUSzpH9Kr97Xdk4a950o9RChBC4 VFP78pl31QtI4u4IFq4lrPPhZtYwexLrnWKQm0iZrtg8Zudc0KTis4nsuHU9+KEaBNkD 4mZ7A7+oTiB19nipKQSaQoLCHJt2Cm4iQnbOuY5Ux/55GxRPKioTp9Cea+MfXEHxnVyl iC3570upsSRNcdODzOqHemXWEA/cArrArr1PeBMT2yPz/QI1bOB0xpD7F4/enluWCr+O DYYunbVYRQy2p8yJis2JGAdh3nanVwVaOgK1oSq996EmBi0GUOMLlZfmAQWDxfACQqPz KA0Q== X-Gm-Message-State: AOJu0YwK12aGU3m987BDHN06RVSscxIWK8BU17gIANv5sO8xm10M7ExQ hyxfk+755csU/YqM5BNZq7eqq/XxAGpqHw== X-Google-Smtp-Source: AGHT+IGr/IunSXbHeInFTd5U6a5FzqYFXtRZCMt13geStc2/zFu+Ok5RzzPc7K5pcoJv5f3uJhWSSQ== X-Received: by 2002:adf:df04:0:b0:315:8a13:ef17 with SMTP id y4-20020adfdf04000000b003158a13ef17mr3886145wrl.65.1691256568243; Sat, 05 Aug 2023 10:29:28 -0700 (PDT) Received: from lumine.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id t12-20020adfe10c000000b0031758e7ba6dsm5607640wrz.40.2023.08.05.10.29.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Aug 2023 10:29:27 -0700 (PDT) Message-ID: <37bb4f1b754a13fe6534dbf2fe204b9ea62b91ea.camel@gmail.com> Subject: Re: Guix and the developer ecosystem From: Liliana Marie Prikler To: Distopico Cc: guix-devel@gnu.org Date: Sat, 05 Aug 2023 19:29:25 +0200 In-Reply-To: <87pm42mfp8.fsf@riseup.net> References: <875y662lmg.fsf@riseup.net> <87pm42mfp8.fsf@riseup.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 MIME-Version: 1.0 Received-SPF: pass client-ip=2a00:1450:4864:20::444; envelope-from=liliana.prikler@gmail.com; helo=mail-wr1-x444.google.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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-Queue-Id: 7BD4F4D8FA X-Migadu-Scanner: mx0.migadu.com X-Migadu-Spam-Score: -5.02 X-Spam-Score: -5.02 X-TUID: 4BCytxXS4WTV Hi Distopico, Am Freitag, dem 04.08.2023 um 20:11 -0500 schrieb Distopico: >=20 > On 2023-07-29, Liliana Marie Prikler > wrote: >=20 > > Hi Distopico > >=20 > > Am Mittwoch, dem 26.07.2023 um 19:29 -0500 schrieb Distopico: > > >=20 > > > Hi, I'm quite new in Guix, I have been using it for 6 months now > > > and I love it, but for development I have not been able to use it > > > as much as I would like. > > "Development" is a loaded term that is understood differently by > > different groups of people.=C2=A0 I personally write software in > > dialects of C and Lisp (yes, even Java if I must), sometimes > > Python, and most of the time Guix at the very least suffices for > > doing so, if it doesn't excel.=C2=A0 Obviously, the holy grail here is = a > > reasonable build system based on GNU tools, CMake or Meson, that > > "modern programming languages" often don't want to employ. > >=20 >=20 > Hi, thank you for your response, well When I say "developer > ecosystem," I'm referring to a significant variety of languages, > whether new or not, to meet the development needs in different > languages compatible with free-software software.=C2=A0 I mean, even if you object in the paragraphs below, Guix already covers a significant variety of languages, probably more so than other system package managers and in any case more so than language-specific ones. =20 > Otherwise, it would be a development environment limited to C, > Python, and a few others, which should be clarified to users to avoid > creating false expectations. By "horizon" or the future vision of the > project, I mean the overall outlook concerning this aspect. Well, as it turns out with generic solutions to problems, they only apply as long as you've modeled your problem accurately enough. And in practice, people also settle for worse. For instance, there's one particular IDE that takes up twice as much disk space if you want to use it for two programming languages. By valuing freedom over anything else, we already have to deal with false expectations when it comes to hardware choices. This is by far not the first time that we're hurt by the consequences of short-sighted to harmful design decisions taking by companies that only care about large numbers. > I can't say that Haskell falls under the category of "modern," but it > has been progressively "modernizing," adapting to the implications, > whether good or bad. Javascript is definitely not new, and TypeScript > is another example that is not new either. Modernity itself is somewhat antiquated, and you can see the same issue with programming languages. We had a talk on postmodern C++ in 2017, so languages that date back to the early 2010s qualify as "modern" in my eye. This also includes Javascript, which although a little older than the rest, through npm pioneered the idea of horking up Python's packaging model even harder. > > > The current programming languages are made up of three [or four] > > > parts: > > >=20 > > > 1. The languages itself > > > 2. Language-server > > > 3. The language packages > > > 4. Language tools (formatter, linter) > > >=20 > > > It is possible to development without a language server, but many > > > projects now require special formatting or running linter tools, > > > etc. These are things that are somewhat basic in a certain way. > > But as with all necessities, just because they're "basic" doesn't > > mean that they're also available to the masses.=C2=A0 There are several > > programming languages, where even getting to a compiler is > > impossible, let alone the other three items on your list.=C2=A0 See [1] > > on why that's a bad idea. > >=20 >=20 > Does Guix have a plan to address this in the future or a workaround? > I believe that in the future, this issue will become even more > common, just as more languages have their own package managers, which > are partly responsible for this huge dependency tree. Let's stash away the thoughts about potential workarounds for now and come back to them later. The plan to address this in the future *is* [1], that is bootstrapping all the tools we don't have (to the best of our ability). > > > In terms of programming languages, I have found almost all the > > > ones I needed, with the exception of Kotlin. > > [2] > >=20 > Thank, good to known that, just curious why/how nix have it. My guess would be that they don't even bother building packages from source in some cases. > > > Regarding language servers, most of the ones I needed either > > > haven't worked for me or don't exist. For example, Rust, Haskell, > > > and Elm have few tools available > > I wonder what all of those have in common.=C2=A0 =F0=9F=A4=94=EF=B8=8F > >=20 > > > [E]ven though I mainly program in Rust and Haskell, and lately, > > > I've been getting into Guile, I also have old projects in Kotlin, > > > for instance, or sometimes I like try other languages when `guix > > > shell` is awesome. > > >=20 > > > So, sometimes I wish to do... > > >=20 > > > ``` > > > guix shell ghc haskell-language-server hlint > > > ``` > > >=20 > > > In that case, the language server isn't available. Another > > > example: > > I mean, you could try packaging it, assuming it has a reasonable > > dependency graph.=C2=A0 Okay, you can stop laughing now. > >=20 >=20 > You are absolutely right. As I mentioned before, the ever-increasing > huge dependency tree is becoming more common in various programming > languages due to the convenience of package managers. It is essential > to have a plan on how to address these situations to ensure the > long-term sustainability and maintainability of projects. Without a > plan, it might be better not to embark on such a journey, as managing > complex dependency chains can lead to numerous challenges and issues > in the future. Projects like Guix need to actively consider > strategies to handle and mitigate these complexities effectively to > ensure a smooth and sustainable development process. In order to effectively create a sustainable development process, we need to break up with the current tradition of cramming the entire internet into a binary and linking that statically, so everyone afterwards has to do the same. Of course, this is a hard solution to roll out, because it is a social one rather than a technical one. Sure, language package managers right now enable you to put almost everything into your code and "have it work". That doesn't mean it's a good idea. In fact, it's a pretty bad one, and one that's at heart of all our software supply chain issues.=20 > >=20 > > > I appreciate the simplicity of Guix, but let's say that Nix has a > > > developer-oriented approach and has become very popular among > > > programmers. Many projects now include default configurations for > > > Nix in their repositories. > > Certainly, Nix enjoys clout, but there's nothing to stop you from > > committing a guix.scm to your favourite project.=C2=A0 Case in point, I > > recently contributed to one such project on Github (via mail to the > > devs, of course). > >=20 >=20 > Well, what holds me back is that many dependencies are missing, such > as the basic ones I mentioned, making it impossible to use Guix in > many cases. Others have non-ideal solutions, like one suggested in > Matrix: `guix shell --container --emulate-fhs' + downloading the > rustup script and installing it just to use clippy (the Rust linter). > So, it's not feasible to include that in the project due to current > limitations. Why the hell is a linter included in your build process in the first place? I can understand that you might want to invoke one before dropping the package maintainers a mail, I mean creating a pull request, but it shouldn't matter otherwise. By the way, remember when I earlier told you we'd come back to workarounds later? Now is later. See, emulating the FHS means that you fake being a regular old Linux distribution whose layout is as Rust would expect without giving it write access to special folders of your actual machine. This is quite powerful indeed. As for packaging clippy, you could try the crate importer, but there's a chance that it does something useless, because Rust decided that their own packaging strategy didn't work for it. The same disclaimer also holds for some GNOME projects that decided to use Rust because it's the new hot stuff and decided not to follow its distribution model. This causes their packages to be form chimaeras of cargo and meson and I don't know why they are actually content with that solution beyond the observation that "it works". =20 > > > Another issue is that if I wanted to bring Guix into the > > > development workflow in a team, there would be the limitation of > > > the OS. While I promote free software in working groups, not > > > everyone uses the same OS - some use GNU/Linux, some use Mac, > > > etc. I think this is also part of the reason why Nix has > > > succeeded in development environments. > > If you have the metal to spare, why not help us ingest some Asahi > > Linux patches? > >=20 >=20 > Well, I think is not a real solution, a lot of time the people with > those mac are from the companies and you are not able to change the > OS, or sometimes you work as a freelancer in a company and other > people use Mac and they don't want to change just becase an > contractor have the idea of use Guix. And that is fine. Recall earlier when I mentioned "reasonable build system based on GNU tools, CMake or Meson"? Those tools work all the same under other operating systems as well. It's not like you have to reinvent them for another programming language. You can still use Guix to improve your flow without forcing everyone to use it. And there's still a chance that at least part of the team will think that it's a great idea, unless they have all sold Steve Jobs their souls. > > > All this text is provided some context for two simple questions: > > >=20 > > > 1. Are there plans in the future to improve integration between > > > development tools? For example, having haskell-language-server > > > for ghc@9.x=C2=A0and another one for ghc@8.x, or something similar to > > > the overwrite feature in Nix flake? > > You mean other than --with-input?=C2=A0 Well, you can pray for the > > upcoming USE flag light parameterized packages to become just that, > > though I personally hope they don't, as there are more interesting > > applications. > >=20 >=20 > Maybe this will be the solution: > https://blog.lispy.tech/parameterized-packages-the-second-update.html The examples provided in that blog are already more interesting than whatever you're trying to solve. > > > 2. Do you see developers as a potential target audience for Guix, > > > or is it mainly focused on HPC (High-Performance Computing)? > > Well, the "developers" Guix sees as target audience typically refer > > to themselves as hackers and don't think of themselves as an elite > > that ought to be given exclusive access to their tools, but rather > > as a vanguard party that wishes to make them available to all. > >=20 > > High performance computing is one application in which Guix makes a > > lot of sense, but there are others ranging from academic over less > > academic to everyday computing, games, and even running stress on > > your CPU, GPU, and what other PUs you can nowadays put into > > hardware to make number go up while the world is literally on fire. > >=20 >=20 > Well, is someone want to hack with Rust/Haskell using Guix is not > possible, They may end up taking alternative paths like in my case, > or a mix of using Guix in some areas and not in others. I don't think the reality is as bleak as you make it out to be. Sure, we probably don't carry cutting-edge versions of most Rust/Haskell stuff out there, but depending on where you sit in the dependency tree, you'll have an easier or harder time. It's quite comfortably around the trunk and rather shaky in the leaves, but it should at least be manageable as long as it's a tree. You'd just have to start actually managing it. Cheers > >=20