From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id eKviF3HhrV/JLgAA0tVLHw (envelope-from ) for ; Fri, 13 Nov 2020 01:29:21 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id AJjCE3HhrV/LXAAA1q6Kng (envelope-from ) for ; Fri, 13 Nov 2020 01:29:21 +0000 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 DAA299402B4 for ; Fri, 13 Nov 2020 01:29:20 +0000 (UTC) Received: from localhost ([::1]:43954 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdNtv-0003Ye-LD for larch@yhetil.org; Thu, 12 Nov 2020 20:29:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45898) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdNtS-0003YK-Jf for guix-devel@gnu.org; Thu, 12 Nov 2020 20:28:50 -0500 Received: from 101a.relay.hey.com ([204.62.115.195]:39477) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kdNtO-0004sO-HQ for guix-devel@gnu.org; Thu, 12 Nov 2020 20:28:50 -0500 Received: from hey.com (bigip-vip-new.rw-ash-int.37signals.com [10.20.0.24]) by 101.relay.hey.com (Postfix) with ESMTP id 39C31A106D; Fri, 13 Nov 2020 01:28:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hey.com; s=heymail; t=1605230925; h=from:from: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; bh=kbYlCvj7F7zpes+aXvO8xkL9zMyD91pLOAHZ+4AUeUs=; b=O64NNPS4NgayPo8F7B4BsukTeleGdLbPnqyOmWhlAs9bLRJ4HZ/gfhdGQXdHp3s40kRRzI nKABqpownASvEav3isFUWYmjs+na+4Wp6Vwd2MknyJO/jnc/g+ocBJHlHW4/HWYq9YvKW+ vtmD4ZKCBu8s2WW4FAt2HH2Y5eiWkO4om6aajWF6C7AgHGb1XX2oYrddrv8STLfptCNItn OoB0ZHKrfap9Tke9v9Q60RDUr/GKPd5TMPsB4hAmL3l8THZ6P2p4NTo/V+qqO0+LJV6M3q NIYh0T2/wqP21qwnX+kaoZQya4ma72FZxoLApN7xXRKE6o1gdzGylRQPd6eY7Q== Date: Fri, 13 Nov 2020 01:28:44 +0000 From: Ryan Prior To: =?UTF-8?B?THVkb3ZpYyBDb3VydMOocw==?= Cc: Development of GNU Guix and the GNU System distribution Message-ID: In-Reply-To: <875z6aguv8.fsf@gnu.org> Subject: Re: Announcing emacs-guix-packaging Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5fade14d25ce6_6d022dc888782"; charset=UTF-8 Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=204.62.115.195; envelope-from=ryanprior@hey.com; helo=101a.relay.hey.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/12 20:28:45 X-ACL-Warn: Detected OS = ??? 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 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-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=hey.com header.s=heymail header.b=O64NNPS4; dmarc=pass (policy=quarantine) header.from=hey.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.21 X-TUID: npoQyZxMa7kd ----==_mimepart_5fade14d25ce6_6d022dc888782 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On November 12, 2020, "Ludovic Court=C3=A8s" wrote:=0D > Looks nice and useful!=0D =0D Thank you! If you end up using it, I'd be interested to hear feedback=0D about what works well and what could go in a different direction.=0D =0D > Did you consider making it part of Emacs-Guix? That=E2=80=99d give us a= single=0D > go-to place for all things Guix in Emacs.=0D =0D I don't use emacs-guix myself. I've tried it a couple times but it's=0D junky. Specifically, it incorporates a lot of custom Guile logic and=0D depends on internal Guix APIs. This design does not benefit anybody.=0D It's harmful for the Guix project because having third-party=0D applications depend on your internal APIs locks you down, where you=0D can't refactor internal logic without breaking other people's stuff. And=0D= it's sad for users because it exposes them to that routine brokenness,=0D= which in my case has prevented me from ever getting any use out of it=0D when I've tried it.=0D =0D And I know I'm not just unlucky: at least once a month we get people in=0D= the IRC or Matrix rooms for Guix who are unable to make emacs-guix work=0D= on their machines. For an interface to Guix, which aims to solve=0D software deployment problems, this is especially cringe-inducing. It=0D shows the fundamental weakness of the package's technical design.=0D =0D So as a result I'm not really interested in contributing to emacs-guix.=0D= I would of course not object if its maintainer wanted to incorporate=0D parts of my package into theirs. They are both GPLv3.=0D =0D On the other hand, I am interested in building out a formal API for=0D tools to interface with Guix without having to depend on its internals=0D= or parse the output of its CLI commands. This could be a Guile API,=0D although I picture json would be a better choice to support diverse=0D tooling.=0D =0D For one example of what I'd want the API for, in my `guix-packaging-=0D insert-input` command I need to get the list of available Guix packages,=0D= and then for the selected package I need to find its scheme symbol. The=0D= emacs-guix approach to those things is to reach into Guix internal data=0D= structures and read out that data, which doesn't deliver results in=0D practice. I opt instead to parse the output of the CLI command `guix=0D package -A ""` as a tsv, which works as long as Guix doesn't change its=0D= output, but that's not guaranteed either.=0D =0D The format of the output from Guix CLI commands varies quite a lot.=0D After parsing the tsv from one command, the next step is to find the=0D corresponding scheme symbol for the chosen package, for which I parse=0D the output of `guix show ` but that's not tsv, that's recfile=0D format. And it doesn't provide the name of the scheme symbol, so I then=0D= go load the source code and look for a `define-public` to scrape the=0D symbol.=0D =0D So what I'd want is a uniform scripting interface where I can query Guix=0D= and get responses in a uniform way, whether that's json, recfile, edn,=0D= msgpack, or Guile s-expressions or whatever. Just so it's an explicitly=0D= documented external API that won't change arbitrarily, doesn't freeze=0D Guix internals, and only requires me to parse one type of output. At=0D some point in the future I can write more about that, and I'm down to=0D contribute the labor to make it happen too. We can use this thread as a=0D= kick-off point for that discussion too if you're interested.=0D =0D But in any case I just wanted to provide some context for why I didn't=0D= build this as an extension to emacs-guix. Hope this helps!=0D =0D Ryan=0D ----==_mimepart_5fade14d25ce6_6d022dc888782 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D
=0D
=0D
On November 12, 2020, "Ludovic Court=C3=A8s" <ludo@gn= u.org> wrote:
Looks nice and useful!

Thank you! If you end up using it, I'd be interested to hear feedbac= k about what works well and what could go in a different direction.
Did you consider making it part of Emacs-Guix? That=E2= =80=99d give us a single
go-to place for all things Guix in Emacs.

I don't use emacs-guix myself. I've tried it a couple t= imes but it's junky. Specifically, it incorporates a lot of custom Guile = logic and depends on internal Guix APIs. This design does not benefit any= body. It's harmful for the Guix project because having third-party applic= ations depend on your internal APIs locks you down, where you can't refac= tor internal logic without breaking other people's stuff. And it's sad fo= r users because it exposes them to that routine brokenness, which in my c= ase has prevented me from ever getting any use out of it when I've tried = it.

And I know I'm not just unlucky: at least once a month we get = people in the IRC or Matrix rooms for Guix who are unable to make emacs-g= uix work on their machines. For an interface to Guix, which aims to solve= software deployment problems, this is especially cringe-inducing. It sho= ws the fundamental weakness of the package's technical design.

So = as a result I'm not really interested in contributing to emacs-guix. I wo= uld of course not object if its maintainer wanted to incorporate parts of= my package into theirs. They are both GPLv3.

On the other hand, I= am interested in building out a formal API for tools to interface with G= uix without having to depend on its internals or parse the output of its = CLI commands. This could be a Guile API, although I picture json would be= a better choice to support diverse tooling.

For one example of wh= at I'd want the API for, in my `guix-packaging-insert-input` command I ne= ed to get the list of available Guix packages, and then for the selected = package I need to find its scheme symbol. The emacs-guix approach to thos= e things is to reach into Guix internal data structures and read out that= data, which doesn't deliver results in practice. I opt instead to parse = the output of the CLI command `guix package -A ""` as a tsv, wh= ich works as long as Guix doesn't change its output, but that's not guara= nteed either.

The format of the output from Guix CLI commands vari= es quite a lot. After parsing the tsv from one command, the next step is = to find the corresponding scheme symbol for the chosen package, for which= I parse the output of `guix show <pkg>` but that's not tsv, that's= recfile format. And it doesn't provide the name of the scheme symbol, so= I then go load the source code and look for a `define-public` to scrape = the symbol.

So what I'd want is a uniform scripting interface wher= e I can query Guix and get responses in a uniform way, whether that's jso= n, recfile, edn, msgpack, or Guile s-expressions or whatever. Just so it'= s an explicitly documented external API that won't change arbitrarily, do= esn't freeze Guix internals, and only requires me to parse one type of ou= tput. At some point in the future I can write more about that, and I'm do= wn to contribute the labor to make it happen too. We can use this thread = as a kick-off point for that discussion too if you're interested.

= But in any case I just wanted to provide some context for why I didn't bu= ild this as an extension to emacs-guix. Hope this helps!

Ryan=0D
=0D =0D =0D
=0D =0D =0D ----==_mimepart_5fade14d25ce6_6d022dc888782--