From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id +NDkBi+ozWQAHQEASxT56A (envelope-from ) for ; Sat, 05 Aug 2023 03:38:55 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id QBjsBi+ozWT8sAAA9RJhRA (envelope-from ) for ; Sat, 05 Aug 2023 03:38:55 +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 A1FD0482F4 for ; Sat, 5 Aug 2023 03:38:53 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=riseup.net header.s=squak header.b=q76mLmpo; 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=riseup.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1691199534; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=gwOeaiEWDuywGiMUAWVUwk8uttKaAV6/jZ3vN1G1GYo=; b=BTgbpAh8BGalMoKT3VG0JQMqJU1yPgPiEvSBI2r5es4U5Du4FvdJDzdbLRJI+6cmYW0fUr l6as2uRk2vgwQSEwMTKRe+9Rm3tRbx70dXUSMvt6IJAzN5nJstXA9RX6fXJQmfEamIyDRt D19SSiAFWqb8XgnaFcc5YfMjXMuk0tOE1Z1RD3k/1qwhJqHgma+pD2bKyU68Fy1aQwGAuN njZpckVQZ7Hwk8Mo2R3ceXxaXx0djo6YtdqzdD+Ze9f5jPOA58gOJaU06VpbCiq0t6GjA1 JUBqLhkoq+V64V10WSUcczO5GXbtb4xfSXHS0EoWXNN2YdbvjPGcwGP7d800hQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=riseup.net header.s=squak header.b=q76mLmpo; 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=riseup.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1691199534; a=rsa-sha256; cv=none; b=U0fIKqBzvOlr/fHYWWir7cTvf7j3dOmeYScsH7x8l5GBewxfAUMuegsvMem2ZgtKof/WPD fMzWe0kBbTpQS24QYXaYt+UpNMzwdX5e5WyOmmNNekJwWhoQzJLHSESVSgPOYlw6Z0Y4br kCT1kudI5tXLdnrnF9lmWhF3w935z5pVN1D/USHL4V8AsaS57YMse9OTUiwWvSGGlRxidM OMYyZO670NBlrrkqu276cfREKmeJ1InCoXWWSN7yUZaRf3h6WhsF0kY7dPThMJ5qK+0tFg Abc9fJRAxnlkAdTKqLOhWbGTA6XQ2eKS6ZQKaRI/N6AGc97KOH70K62KaZA8HQ== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qS6FJ-0006oK-V8; Fri, 04 Aug 2023 21:38:21 -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 1qS6FI-0006jH-9v for guix-devel@gnu.org; Fri, 04 Aug 2023 21:38:20 -0400 Received: from mx1.riseup.net ([198.252.153.129]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qS6FF-0003jt-Qn for guix-devel@gnu.org; Fri, 04 Aug 2023 21:38:20 -0400 Received: from fews02-sea.riseup.net (fews02-sea-pn.riseup.net [10.0.1.112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx1.riseup.net (Postfix) with ESMTPS id 4RHlbC3S46zDrnQ; Sat, 5 Aug 2023 01:38:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1691199495; bh=Htqhfp1CPcCuz6zVRue3D9IP/4aRuqJYJISoRUrI3Z8=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=q76mLmpogfWN8EqgWLZRCgoeQS3hQGpCfW7M+Qvoiijg6+ovMFSd5tnBpMKzVsMMf agrM1X6M5Qc/f97b5uGiWLXoc5HE0cwYrX1vu5DSo+E8iMTM2hXQss2VdsjrAWKUzz D8ap/sUpsDXW8WZUeAa8/FRPc/xnwkV8MuLR49uk= X-Riseup-User-ID: 516590EF0FD4C272D53D4F3079C8AAB5F11E864DF14BB269FA75099E8648B39B Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews02-sea.riseup.net (Postfix) with ESMTPSA id 4RHlbB5MynzFq38; Sat, 5 Aug 2023 01:38:14 +0000 (UTC) References: <875y662lmg.fsf@riseup.net> From: Distopico To: Liliana Marie Prikler Cc: guix-devel@gnu.org Subject: Re: Guix and the developer ecosystem Date: Fri, 04 Aug 2023 20:11:24 -0500 In-reply-to: Message-ID: <87pm42mfp8.fsf@riseup.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Received-SPF: pass client-ip=198.252.153.129; envelope-from=distopico@riseup.net; helo=mx1.riseup.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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-Queue-Id: A1FD0482F4 X-Migadu-Scanner: mx1.migadu.com X-Spam-Score: -8.79 X-Migadu-Spam-Score: -8.79 X-TUID: PBziiDG3Co77 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2023-07-29, Liliana Marie Prikler wrote: > Hi Distopico > > 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. 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. 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. > 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. 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. 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. >> 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. There are several > programming languages, where even getting to a compiler is impossible, > let alone the other three items on your list. See [1] on why that's a > bad idea. > 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. >> In terms of programming languages, I have found almost all the ones I >> needed, with the exception of Kotlin. > [2] > Thank, good to known that, just curious why/how nix have it. >> 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. =F0=9F=A4=94=EF=B8=8F > >> [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. Okay, you can stop laughing now. > 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. >> ``` >> guix shell rust@1.67.1=C2=A0rust-analizer rust-clippy >> ``` >>=20 >> In that case, rust-analyzer won't be compatible with that version of >> Rust, and the version of rust-analyzer is broken (I sent a patch >> fixing it). > --with-input to the rescue. > Nice, I'll try it, thank you >> 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. Case in point, I > recently contributed to one such project on Github (via mail to the > devs, of course). > 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. >> 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? > 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 wan to change just becase an contractor have the idea of use Guix. >> 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? 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. > Maybe this will be the solution: https://blog.lispy.tech/parameterized-packages-the-second-update.html >> 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. > > 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. > 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 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. > There is only one direction, and that is forward. > For sure, thank you. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFJBAEBCAAzFiEEvYwofabWO6y953lVmAk6gHJUa/MFAmTNqAMVHGRpc3RvcGlj b0ByaXNldXAubmV0AAoJEJgJOoByVGvzNQoH/01WGTM7s/FnKZoDSxNcIvNmz1jj lnhjKMOERnVnq3Iam8jIA9mm366VZZ7XGrSpeaS1PU+FgrzxjIp4NFYYpwwpZMFK EFai89o6W38DANWVQO8lZRxoQ4OB6oCluZeK7yMZOTI3m0ZjF3kzASP4S5RM7dPS Ds289BBLTsx93fWswWTyLNwtW3rNeK+ISfbadzCt+ELvXKvRcdfyq00HxTQK/+L6 zSvoJVDHG+TAslc2XG1eZ5LzcI1W+NnhO3XvOvuA9DByecth3nyNh2bEq/shJ151 rPLc/58yKgbCCRa5e1tiotOCIVPrTBwWKruDDhCUrYVWZqKlDLsBnh8AX8o= =Xxpp -----END PGP SIGNATURE----- --=-=-=--