From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id gPFcBE0eSGOM+wAAbAwnHQ (envelope-from ) for ; Thu, 13 Oct 2022 16:18:53 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id 6A9jBE0eSGOTBwEAauVa8A (envelope-from ) for ; Thu, 13 Oct 2022 16:18:53 +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 D80F83D63F for ; Thu, 13 Oct 2022 16:18:52 +0200 (CEST) Received: from localhost ([::1]:45800 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oiz2y-00075H-0m for larch@yhetil.org; Thu, 13 Oct 2022 10:18:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56844) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiz1x-00072Q-JQ for guix-devel@gnu.org; Thu, 13 Oct 2022 10:17:50 -0400 Received: from [37.120.193.124] (port=35606 helo=mail.cock.li) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiz1r-0007hK-8s for guix-devel@gnu.org; Thu, 13 Oct 2022 10:17:49 -0400 References: <20221013010703.GB27375@dismail.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=airmail.cc; s=mail; t=1665670598; bh=AKKHDNhJqo7ypPIsahh+A+a/GiBigy70yQiELeFEEnY=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=XoR0dsuDoANvozIkM3Kt2zGSOn8RCILEe7HQ/CAG8lKGcdB+OUwvSXPaCTZvHJEnI NsInn8E/ck3NPsODrxRYBRa5VFil01gOVBb+0kYxx3XW4eB34ziPiuyocd569RvThE rBRBcRlAJjmCMhMlfv4Li1Hj0iiq6adB0C7TiLyP7pD7g82GXlXtU/XtMvZtTh1fTs XTnELIph5Sc0cDV18ilKNr7VVq9GrPq+5uW+8dRFSWbmStb2ZFiDzHU2Iz6DM0N2Ae Of1Jt994gRB2+1JKqZcdyyPA7cc64ZwMvNPXfL++LaKYern84rG/hvAU0HzWtxJSo1 DKsWaAUqBov9A== User-agent: mu4e 1.8.9; emacs 28.1 From: pinoaffe To: jgart Cc: guix-devel@gnu.org Subject: Re: Guix Goals: One Hackable Developer Tool To Rule Them All Date: Thu, 13 Oct 2022 15:56:15 +0200 In-reply-to: <20221013010703.GB27375@dismail.de> Message-ID: <87a65zrepm.fsf@airmail.cc> MIME-Version: 1.0 Content-Type: text/plain X-Host-Lookup-Failed: Reverse DNS lookup failed for 37.120.193.124 (failed) Received-SPF: pass client-ip=37.120.193.124; envelope-from=pinoaffe@airmail.cc; helo=mail.cock.li X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 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, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no 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" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1665670732; 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=UzmaMXo1Sxf5yV8SXLnpg/4uSrSi33FO91nvVuUkHRM=; b=A7EfUeMH7lyF31k9j+sJpZ1EXvegKJVi6lim+txDbnN/NaWDJcNpu1/QaJW6bOlNxQtQZa 517FB+nUIW+uyARc0f4XDj0OMKxTaCtqYmqD6N8r6Yda9BRBparfPwkYXnRqmjGnEOb4At IjlVoiGowFCQDgMRR1xPZUh2YI0SAiqVpNhoCjgT6x+JV5PwIJcL9oiKP5Zxn7pDbXqinV MxCp2oh4ATJAgpVHkaDhIRbGB2hqS5V8+AKGXCbSxVV8sbA2Pp0JekvHozLntEJmLRxBSf PBmNDPqKkm2bnhzSgW9HqLb0pDe0C54wkoicNkYn3ZtCe2MTS0nyWltC9VvChg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1665670732; a=rsa-sha256; cv=none; b=AIYZSvxlrCtY2zIMgbqDlvNM8ik24ekYd+R7wOvHpS9z7zOxzbBBSolXsfl/p/4qnYuR26 kS5be5+vWUnmahGp4l56IM/JrGP2Jb4HZtrXHq9QIsVatGYxxDRwE2EafunsIPbYSo57Tw kuPzL3ZXKJrn4MUkG4g2AEOSkFxV7VYovqgUairx1TqyWB7C5nLPuN8imrV8SvZ7vDWaGm vM4FWtTTn+Qo0QeEO6o6vxwiI+FXpsDrNC6W0JUShYjn41pv3xlqweH/3Ij98r6Hx3qS9T 8iTfVCT3eNhw9DadwkwtiCNgaN+VejIo44sXWUauxOc40eFpJdhZBItDSdKdbg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=airmail.cc header.s=mail header.b=XoR0dsuD; dmarc=none; 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" X-Migadu-Spam-Score: -3.70 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=airmail.cc header.s=mail header.b=XoR0dsuD; dmarc=none; 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" X-Migadu-Queue-Id: D80F83D63F X-Spam-Score: -3.70 X-Migadu-Scanner: scn0.migadu.com X-TUID: 8m/t/vmzzwFz Hi, I think that (if done well) this would greatly simplify my workflow in many software projects, so I think it's a good idea. In the rest of my email, I more or less assume that there is a one-to-one correspondence between software projects and guix packages, even though this is clearly not the case. I nonetheless make this assumption since it is the case (or can be made the case) for many of the software projects on which one might want to work using guix. jgart writes: > The various language ecosystems have their own linters, formatters, > typecheckers, repls, test runners, etc. > > What if Guix could manage them all? > > `guix lint` in a python project would run mypy. > `guix lint` in a haskell project would run hlint. > `guix lint` in an erlang project would run dialyzer. These would require some sort of configurability, since most languages/projects have not just one linter. Even if there's a "monopoly" there might be different settings/versions of said linter. Do you propose that such configuration is added to packages? Or should this go somewhere else? Furthermore, in many projects there are various different languages at once (e.g., a python webapp with client-side javascript and css), so it would probably be useful to mirror the build-phases approach in guix packaging. It might even be possible to set up (somewhat) sane defaults based on the build-system used by the local project. > `guix fmt` in a python project would run black. > `guix fmt` in a haskell project would run ormolu. > `guix fmt` in a erlang project would run erlfmt. My comments regarding linters apply here as well > `guix repl` in a python project would run ptpython or some other configured repl. > `guix repl` in a haskell project would run ghci. > `guix repl` in a erlang project would run erl. This should be fairly easy to implement, assuming that there is just one repl associated to each project one might want to use this command with. It should (imo) be possible to configure/pass arguments to the repl on a per-project basis and whenever you run `guix repl` > `guix test` in a python project would run pytest or unittest. > `guix test` in a haskell project would run hunit. > `guix test` in a erlang project would run eunit. Should I read this as a proposal to add an extra command to build (and test) the local project's guix package, or do you propose to make this do something different? Because I'm not sure the latter would be a good idea, if there is a need to do testing in some other way than currently possible I'd think it would be more valuable (and more clean) to extend the current testing facilities to incorporate this. > `guix run` in a python project could start a flask app listening on a particular port. > `guix run` in a ruby project could start a puma server. > `guix run` in a haskell project could run a pre-configured script or Main.hs > `guix run` in a erlang project could start a cowboy server. I'm not sure how widely this may be applicable, since many projects or packages don't have just one way to run them, they may even contain several different executables or modules. > The idea would be to have Guix provide a configurable CLI wrapper > subcommand around all language ecosystem developer tools. In other words > it's the same Guixy thesis applied to developer tooling. I think this > could take the Guix developer experience to the next level. Kind regards, pinoaffe