From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id yJBsHDNh12UaEgEAe85BDQ:P1 (envelope-from ) for ; Thu, 22 Feb 2024 15:58:59 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id yJBsHDNh12UaEgEAe85BDQ (envelope-from ) for ; Thu, 22 Feb 2024 15:58:59 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r24 header.b=caijxuMl; 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=telenet.be ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1708613932; 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=P7eFwoCV88xcas0FY787phCjesXHUUDUzct5DeY6Wvk=; b=sua7Zl2U23EdfQM5Jwv6VXCQTmz+fKAmspymAepGc9MfJSDOZCkoIdLLzUM77gRfkbxMX+ ItOcrScQ6A9MOOshxH0PDCuFCoy3g3jqY0Rz7dWtqmoggMWTT+8mrTVXkjoBJZs8HPVbXV U0aYS1H8LkYzN6F8aNLLP/aN7NZJTqwZ8gLU9XBn7IZF8P6aHZdgjMJ1mrMf7Rix1Z0l+e aUg7aJmZ3p7vOGWCOHhIxJsDW/SHjj6Y3zes6NQILRZ1/rAhytX8fKx1Ty4MXJJzeYt/ID fLkVmfg+L3k/pfNcegD8JePwWul45IT9VaAdRyp63X3alkGJFQ81emV0LKao1A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=telenet.be header.s=r24 header.b=caijxuMl; 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=telenet.be ARC-Seal: i=1; s=key1; d=yhetil.org; t=1708613932; a=rsa-sha256; cv=none; b=aklvXjvJn3n3oukGwvAfEYdFft6K/SBHPwOulmUL+rjFQj0cnknhu8TDtXqz9x87S4W12R jRTC3JRJN2yVWbx6368qT9V54NgP7CP27W8BfmryehLeWx2Vc22BsWOn0SNEN8DJht6tP/ ghEMLK90HcfXsWkaRk8qJxlcy9mKG7kw874w0dY1lXpFxbnR3NEcGjMsDO22WOzpqyc/p3 I93is544zm9FHvJwCvmQYK7gyn4um2TrYxe28XDDhj+kpgZq8vM5SFNGgRapBNwwS+U8Gs 2F0SLq4pPbpA2RZF4oyeV+tQwMBSog3qVbCztiFmyKIdQglNiKT/YFxLuVYa9w== 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 041D525553 for ; Thu, 22 Feb 2024 15:58:52 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rdAWH-0006jP-V2; Thu, 22 Feb 2024 09:57:53 -0500 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 1rdAWG-0006j7-3G for guix-devel@gnu.org; Thu, 22 Feb 2024 09:57:52 -0500 Received: from andre.telenet-ops.be ([2a02:1800:120:4::f00:15]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rdAWC-0003PM-Ag for guix-devel@gnu.org; Thu, 22 Feb 2024 09:57:51 -0500 Received: from [IPv6:2a02:1808:84:91fd:b8e9:ae87:8763:bb2a] ([IPv6:2a02:1808:84:91fd:b8e9:ae87:8763:bb2a]) by andre.telenet-ops.be with bizsmtp id qExg2B0021q4WC401Exg6J; Thu, 22 Feb 2024 15:57:41 +0100 Message-ID: <20240222155741.qExg2B0021q4WC401Exg6J@andre.telenet-ops.be> MIME-Version: 1.0 To: Steve George Cc: "guix-devel@gnu.org" , r0man , Reilly Siegel From: Maxime Devos Subject: RE: Proposal to turn off AOT in clojure-build-system Date: Thu, 22 Feb 2024 15:57:41 +0100 Importance: normal X-Priority: 3 In-Reply-To: References: <20240219154444.p2kj2B0094wMGJ4012kk71@baptiste.telenet-ops.be> Content-Type: multipart/alternative; boundary="_E938766D-F9CD-4FCA-9529-B7086F540E3A_" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=telenet.be; s=r24; t=1708613861; bh=IrwYKWr7eWH5ozBz/PVikeT5GwtLrq7UBVy99iHl20c=; h=To:Cc:From:Subject:Date:In-Reply-To:References; b=caijxuMl4Sx0ksmAcBtxx6MOloDRnC15i1knVRTmDQtPJU8yeZUjLZxQk3Uivl334 wn73aGlEzI9GkzD4NczQqly1oVcPltR5ifs7ih0pFJSPAXbdsiGaPeLa7szKSZ4bG7 kSL/yCCYfo2E9DrqmThdN9LhpnsHt8sAH2g1htja/+p3cCKSI/+hW5zfIUapr7lVAZ 8qYmbbkZ2bkJ8Ah4VVVcoYSkb0b3em8Gp+O30i822pby9BaazL7AZHlvxCpiz5oXc+ NFM/McQrJfR3XIu45CiX1e/oAigSoLMfZQMKtYX/dqzzD9/zskUAsIkhN34FdMapcQ 5zsXUJBko0pAg== Received-SPF: pass client-ip=2a02:1800:120:4::f00:15; envelope-from=maximedevos@telenet.be; helo=andre.telenet-ops.be 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -7.78 X-Spam-Score: -7.78 X-Migadu-Queue-Id: 041D525553 X-TUID: sJ7xXCLLr96P --_E938766D-F9CD-4FCA-9529-B7086F540E3A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" >> [...]=20 >> > But, I would like to draw attention to this thread on Clojureverse as = the best source I could find: >> >Alex Miller is the main community manager for Clojure, and is a maintai= ner of the core libraries, so his perspective is key. He notes that, AOT co= de is tied to *specific versions of Clojure*: >> > >> > "AOT'ed code is that it is inherently the product of a particular ver= sion of tthe Clojure compiler ... I would recommend NOT AOT compiling libra= ries" [4] >>=20 >> This reasoning does not follow =E2=80=93 yes, it is tied to the Clojure = version, so what? Guix automatically rebuilds dependents when the dependenc= y (in this case, the Clojure compiler) changes. (...) >I think this preceding sentence is the heart of different assumptions betw= een us. >The Clojure packages we haave are for developers writing applications (lib= raries and tools). The ecosystem has very few end-user applications [0]. As= a Clojure developer I can use the Clojure tools from Guix, and a few libra= ries. We (and all the other distributions) have a miniscule portion of the = Clojure/Java library universe [1]. This leads to the following usage scenar= ios: >1. A developer installs Clojure from Guix, and uses libraries from outside= Guix. They can install the JVM/Clojure and some common tools (like clj-tools-cli)= . They will use libraries from elsewhere, including their own. AOT compilat= ion is a problem because of the issue of mixed AOT and non-AOT. >2. A developer installs a Clojure from outside Guix, uses libraries from i= nside Guix This will cause problems because the Guix Clojure libraries will have been = AOT'd by a different version of the compiler. It's also fairly common to in= stall/use parallel versions of Clojure/jvm due to different deployment need= s, this is likely to cause difficult to find bugs. My answer to (1) and (2) is: (a) About =E2=80=9Cinstall Clojure from outside Guix + use libraries inside= Guix=E2=80=9D: If these libraries are AOT: Don=E2=80=99t do that, then. If you mix-and-match binaries (in this case, .= class files) different distributions, you are free to do so, but when (not = if, when) things break, you get to keep the pieces. If these libraries are just the .clj files (not AOT) (which as I understand= it is the standard situation): doesn=E2=80=99t seem a problem to me (see p= oint (b)). Adding source from other places is one thing (probably ok), adding binaries= is another (probably not ok, especially if unstable ABIs (see Clojure comp= iler) and mismatched versions (see hypotheses of 2.) are involved. (b) What is this =E2=80=9Cthe issue of mixed AOT and non-AOT=E2=80=9D? Do y= ou have a source on this? Besides Clojure supposedly, I haven=E2=80=99t eve= r heard of such problems for any language =E2=80=93 for example, there is n= o such issue with Guile and AFAIK not for Python. I haven=E2=80=99t heard o= f any such issues for the Common Lisp implementations either (though I have= n=E2=80=99t checked), so this doesn=E2=80=99t seem like a =E2=80=9CClojure = doesn=E2=80=99t do hygienic macros=E2=80=9D issue. (c) Guix isn=E2=80=99t forcing anyone to use AOT=E2=80=99d libraries. If pe= ople really want to assist in murdering the climate (or its a situation whe= re total cost of non-AOT is lower than AOT), they can unfortunately (*) sim= ply do so applying a recursive transformation that adds #:aot? #false flags= everywhere or whatever the exact argument is (**). Given that this transformation has some legitimate use cases, this transfor= mation could even be a pre-canned procedure + transformation included in Gu= ix itself (*) =E2=80=98unfortunately=E2=80=99 only applies to the first case. For the= case in parentheses, replace by =E2=80=98fortunately=E2=80=99. (**) IIRC is wasn=E2=80=99t #:aot? but some other name, but that=E2=80=99s = not really the point here. (d) If a deployment need multiple versions of Clojure, then just fix your d= eployment to make everything work with the latest version of Clojure. Or, i= f you for some reason don=E2=80=99t do that, just use a (recursive) transfo= rmation to change the version of the Clojure compiler used to match the Clo= jure that will be used in the particular deployment. (e) You can simply add missing packages to Guix as the need arises. >I can see the sense of compiling to byte code if it's an end-user applicat= ion. In that case we'd want to make the start-up as fast as possible. Your = comments seem to have this use-case in mind. >But, today there aren't any such end-user Clojure applications in Guix. That=E2=80=99s a shame. Hopefully that will change some day. Also, this is false, =E2=80=9Cclojure-tools=E2=80=9D exists =E2=80=93 devel= opers are people too (I don=E2=80=99t care about the =E2=80=9C_end_-user=E2= =80=9D distinction =E2=80=93 surely developers want fast start-up as well). Also, I _don=E2=80=99t_ have that use case in mind =E2=80=93 I have efficie= ncy in general in mind, efficiency of the start-up is only a part of that. The point is: most likely you will want the application to have AOT code, a= nd that library has dependencies. Furthermore, likely many of these depende= ncies are dependencies of other applications as well. Instead of redoing the compilation of N shared dependencies for each M appl= ications (total work: ~N*M), by not participating in these Clojure convent= ions, the total work of compiling dependencies can be reduced to ~N). Let=E2=80=99s avoid joining the madness that is Go=E2=80=99s build system a= nd Cargo(*). (*) Rust is fine for compilation, it=E2=80=99s cargo that is the problem (a= t least, Cargo as used by Guix) =E2=80=93 antioxidant (https://notabug.org/= maximed/cargoless-rust-experiments) avoids the sheer inefficiency of Cargo. >> >I believe this means that with AOT code on, any user who installs a dif= ferent version of Clojure from the one that we used to AOT the libraries *m= ay* have problems. >>=20 >> Unlike, say, Maven, this situation simply does not happen in Guix, becau= se we don=E2=80=99t just download binaries and call it a day (except for so= me bootstrapping stuff, but that=E2=80=99s not relevant for Clojure AOT), b= ecause we have functioning recompilation of dependents, because of shebang = patching, because binaries that are to be invoked should not rely on the am= bient CLASSPATH / LD_LIBRARY_PATH / etc. and, if, the underlying binaries d= o rely on that, they are wrapped (see wrap-program) to set them (or, at lea= st, they should be, you might find some bugs in this department if you go l= ooking). >>=20 >> Even if they aren=E2=80=99t wrapped, then in that case the dependencies = are propagated-inputs, and you can only have a single version of a propagat= ed package in the same environment (barring stacking environment shenanigan= s, but then you are looking for it and/or you can just report a bug about h= ow the binaries should be wrapped/classpath should be patched in/...). >=20 >In this paragraph you're assumption is that a Guix user is only using libr= aries from within Guix. Hopefully, I've shown why this assumption is unlike= ly above. You haven=E2=80=99t. You have shown that other situations exist, not that t= his situation is unlikely. To demonstrate likelihood / unlikelyhood, you ne= ed some statistics (or a very thorough argument on why people wouldn=E2=80= =99t just make a package for missing dependencies =E2=80=93 it=E2=80=99s ve= ry simple, especially if you aren=E2=80=99t sending them for inclusion.) >You also mentioned Debian, and @e.hashiman [2] said that Clojure libraries= are not AOT'd on Debian, while applications are. From what I can find ther= e are 130 packages in Debian with the word Clojure in them [3]. I looked at= a selection and it seems true that Debian does not AOT libraries (and I ca= n't find any Clojure 'apps'). For completeness I also checked what Clojars,= the main distribution archive for Clojure developers, does: > [...] OK ... and? Other people doing things differently doesn=E2=80=99t mean thos= e different approaches are better. If Debian mentions somewhere the reason = _why_ it doesn=E2=80=99t AOT libraries, that reason can be investigated and= perhaps carried over to Guix, but it=E2=80=99s the =E2=80=98why=E2=80=99 t= hat=E2=80=99s important, not the =E2=80=98it doesn=E2=80=99t=E2=80=99. > Does this help clarify why I'm asking to change the default? Yes. It appears you are unfamiliar with the =E2=80=9Ctransformations=E2=80= =9D functionality of Guix, which allows for easy rewriting of packages to w= hatever Clojure version you want, eliminating compatibility concerns or eve= n turning off AOT completely. (This requires the relevant versions of Clojure to be packaged in Guix, but= that shouldn=E2=80=99t be too much of a problem.) It also appears you are unfamiliar with Guix importers, which easily make p= ackage definitions (somewhat low quality w.r.t. descriptions, with lack of = verification of freeness, etc., but usually otherwise fully functional). I = don=E2=80=99t know if an importer for Clojure exists but it shouldn=E2=80= =99t be too difficult I think. Best regards, Maxime Devos. --_E938766D-F9CD-4FCA-9529-B7086F540E3A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

>> [...]

>> > But, I would like to draw attention to= this thread on Clojureverse as the best source I could find:

>> >Alex Miller is the main community manager for Clo= jure, and is a maintainer of the core libraries, so his perspective is key.= He notes that, AOT code is tied to *specific versions of Clojure*:

>> >

>> >=C2=A0 = "AOT'ed code is that it is inherently the product of a particular vers= ion of tthe Clojure compiler ... I would recommend NOT AOT compiling librar= ies" [4]

>>

>= ;> This reasoning does not follow =E2=80=93 yes, it is tied to the Cloju= re version, so what? Guix automatically rebuilds dependents when the depend= ency (in this case, the Clojure compiler) changes.

= (...)

 

>= ;I think this preceding sentence is the heart of different assumptions betw= een us.

 

&= gt;The Clojure packages we haave are for developers writing applications (l= ibraries and tools). The ecosystem has very few end-user applications [0]. = As a Clojure developer I can use the Clojure tools from Guix, and a few lib= raries. We (and all the other distributions) have a miniscule portion of th= e Clojure/Java library universe [1]. This leads to the following usage scen= arios:

 

&g= t;1. A developer installs Clojure from Guix, and uses libraries from outsid= e Guix.

They can install the JVM/Clojure and some c= ommon tools (like clj-tools-cli). They will use libraries from elsewhere, i= ncluding their own. AOT compilation is a problem because of the issue of mi= xed AOT and non-AOT.

 

>2. A developer installs a Clojure from outside Guix, uses = libraries from inside Guix

This will cause problems= because the Guix Clojure libraries will have been AOT'd by a different ver= sion of the compiler. It's also fairly common to install/use parallel versi= ons of Clojure/jvm due to different deployment needs, this is likely to cau= se difficult to find bugs.

 

My answer to (1) and (2) is:

 

(a) About =E2=80=9Cinstall Clojure fr= om outside Guix + use libraries inside Guix=E2=80=9D:

 

If these libraries are AOT:

 

Don=E2=80= =99t do that, then. If you mix-and-match binaries (in this case, .class fil= es) different distributions, you are free to do so, but when (not if, when)= things break, you get to keep the pieces.

&nb= sp;

If these libraries are just the .clj file= s (not AOT) (which as I understand it is the standard situation): doesn=E2= =80=99t seem a problem to me (see point (b)).

=  

Adding source from other places is one= thing (probably ok), adding binaries is another (probably not ok, especial= ly if unstable ABIs (see Clojure compiler) and mismatched versions (see hyp= otheses of 2.) are involved.

 

<= p class=3DMsoNormal>(b) What is this =E2=80=9Cthe issue of mixed AOT and no= n-AOT=E2=80=9D? Do you have a source on this? Besides Clojure supposedly, I= haven=E2=80=99t ever heard of such problems for any language =E2=80=93 for= example, there is no such issue with Guile and AFAIK not for Python. I hav= en=E2=80=99t heard of any such issues for the Common Lisp implementations e= ither (though I haven=E2=80=99t checked), so this doesn=E2=80=99t seem like= a =E2=80=9CClojure doesn=E2=80=99t do hygienic macros=E2=80=9D issue.

<= p class=3DMsoNormal> 

(c) Guix isn= =E2=80=99t forcing anyone to use AOT=E2=80=99d libraries. If people really = want to assist in murdering the climate (or its a situation where total cos= t of non-AOT is lower than AOT), they can unfortunately (*) simply do so ap= plying a recursive transformation that adds #:aot? #false flags everywhere = or whatever the exact argument is (**).

 =

Given that this transformation has some legi= timate use cases, this transformation could even be a pre-canned procedure = + transformation included in Guix itself

 = ;

(*) =E2=80=98unfortunately=E2=80=99 only ap= plies to the first case. For the case in parentheses, replace by =E2=80=98f= ortunately=E2=80=99.

(**) IIRC is wasn=E2=80=99t #:= aot? but some other name, but that=E2=80=99s not really the point here.

=

 

(d) If a dep= loyment need multiple versions of Clojure, then just fix your deployment to= make everything work with the latest version of Clojure. Or, if you for so= me reason don=E2=80=99t do that, just use a (recursive) transformation to c= hange the version of the Clojure compiler used to match the Clojure that wi= ll be used in the particular deployment.

 = ;

(e) You can simply add missing packages to = Guix as the need arises.

 

>I can see the sense of compiling to byte code if it's a= n end-user application. In that case we'd want to make the start-up as fast= as possible. Your comments seem to have this use-case in mind.

 

>But, today there= aren't any such end-user Clojure applications in Guix.

 

That=E2=80=99s a shame. Hope= fully that will change some day.

Also, this is fals= e, =E2=80=9Cclojure-tools=E2=80=9D exists =E2=80=93 developers are people t= oo (I don=E2=80=99t care about the =E2=80=9C_end_-user=E2=80=9D distinction= =E2=80=93 surely developers want fast start-up as well).

 

Also, I _don=E2=80=99t<= /i>_ have that use case in mind =E2=80=93 I have efficiency in general in m= ind, efficiency of the start-up is only a part of that.

 

The point is: most likely yo= u will want the application to have AOT code, and that library has dependen= cies. Furthermore, likely many of these dependencies are dependencies of ot= her applications as well.

 

Instead of redoing the compilation of N shared dependencie= s for each M applications=C2=A0 (total work: ~N*M), by not participating in= these Clojure conventions, the total work of compiling dependencies can be= reduced to ~N).

 

Let=E2=80=99s avoid joining the madness that is Go=E2=80=99s build = system and Cargo(*).

 

(*) Rust is fine for compilation, it=E2=80=99s cargo that is t= he problem (at least, Cargo as used by Guix) =E2=80=93 antioxidant (https://notabug= .org/maximed/cargoless-rust-experiments) avoids the sheer inefficiency = of Cargo.

 

>> >I believe this means that with AOT code on, any user who inst= alls a different version of Clojure from the one that we used to AOT the li= braries *may* have problems.

>>

>> Unlike, say, Maven, this situation simply does not ha= ppen in Guix, because we don=E2=80=99t just download binaries and call it a= day (except for some bootstrapping stuff, but that=E2=80=99s not relevant = for Clojure AOT), because we have functioning recompilation of dependents, = because of shebang patching, because binaries that are to be invoked should= not rely on the ambient CLASSPATH / LD_LIBRARY_PATH / etc. and, if, the un= derlying binaries do rely on that, they are wrapped (see wrap-program) to s= et them (or, at least, they should be, you might find some bugs in this dep= artment if you go looking).

>>

>> Even if they aren=E2=80=99t wrapped, then in that cas= e the dependencies are propagated-inputs, and you can only have a single ve= rsion of a propagated package in the same environment (barring stacking env= ironment shenanigans, but then you are looking for it and/or you can just r= eport a bug about how the binaries should be wrapped/classpath should be pa= tched in/...).

>

&= nbsp;

>In this paragraph you're assumption= is that a Guix user is only using libraries from within Guix. Hopefully, I= 've shown why this assumption is unlikely above.

 

You haven=E2=80=99t. You have shown= that other situations exist, not that this situation is unlikely. To demon= strate likelihood / unlikelyhood, you need some statistics (or a very thoro= ugh argument on why people wouldn=E2=80=99t just make a package for missing= dependencies =E2=80=93 it=E2=80=99s very simple, especially if you aren=E2= =80=99t sending them for inclusion.)

 

>You also mentioned Debian, and @e.hashiman = [2] said that Clojure libraries are not AOT'd on Debian, while applications= are. From what I can find there are 130 packages in Debian with the word C= lojure in them [3]. I looked at a selection and it seems true that Debian d= oes not AOT libraries (and I can't find any Clojure 'apps'). For completene= ss I also checked what Clojars, the main distribution archive for Clojure d= evelopers, does:

> [...]

 

OK ... and? Other people doing t= hings differently doesn=E2=80=99t mean those different approaches are bette= r. If Debian mentions somewhere the reason _why_ it doesn=E2=80=99t = AOT libraries, that reason can be investigated and perhaps carried over to = Guix, but it=E2=80=99s the =E2=80=98why=E2=80=99 that=E2=80=99s impo= rtant, not the =E2=80=98it doesn=E2=80=99t=E2=80=99.

 

> Does this help clar= ify why I'm asking to change the default?

&nbs= p;

Yes. It appears you are unfamiliar with th= e =E2=80=9Ctransformations=E2=80=9D functionality of Guix, which allows for= easy rewriting of packages to whatever Clojure version you want, eliminati= ng compatibility concerns or even turning off AOT completely.

 

(This requires the r= elevant versions of Clojure to be packaged in Guix, but that shouldn=E2=80= =99t be too much of a problem.)

&nb= sp;

It also appears you are unfamiliar with G= uix importers, which easily make package definitions (somewhat low quality = w.r.t. descriptions, with lack of verification of freeness, etc., but usual= ly otherwise fully functional). I don=E2=80=99t know if an importer for Clo= jure exists but it shouldn=E2=80=99t be too difficult I think.

 

Best regards,

Maxime Devos.

= --_E938766D-F9CD-4FCA-9529-B7086F540E3A_--