From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id uN6QMgcqV2FyNQAAgWs5BA (envelope-from ) for ; Fri, 01 Oct 2021 17:32:23 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id MP9MLgcqV2EGQgAA1q6Kng (envelope-from ) for ; Fri, 01 Oct 2021 15:32:23 +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 04A21EBE8 for ; Fri, 1 Oct 2021 17:32:23 +0200 (CEST) Received: from localhost ([::1]:60730 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mWKWM-0004so-2s for larch@yhetil.org; Fri, 01 Oct 2021 11:32:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33244) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWKW2-0004qF-JV for guix-patches@gnu.org; Fri, 01 Oct 2021 11:32:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:45600) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mWKW2-0006AU-BF for guix-patches@gnu.org; Fri, 01 Oct 2021 11:32:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mWKW2-0001JJ-2a for guix-patches@gnu.org; Fri, 01 Oct 2021 11:32:02 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#48463] gnu: Add j. Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 01 Oct 2021 15:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48463 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: elaexuotee@wilsonb.com Cc: 48463@debbugs.gnu.org Received: via spool by 48463-submit@debbugs.gnu.org id=B48463.16331022834972 (code B ref 48463); Fri, 01 Oct 2021 15:32:02 +0000 Received: (at 48463) by debbugs.gnu.org; 1 Oct 2021 15:31:23 +0000 Received: from localhost ([127.0.0.1]:57146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mWKVO-0001I8-Ds for submit@debbugs.gnu.org; Fri, 01 Oct 2021 11:31:22 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:47067) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mWKVL-0001Hl-IZ for 48463@debbugs.gnu.org; Fri, 01 Oct 2021 11:31:20 -0400 Received: by mail-wr1-f67.google.com with SMTP id k7so15982161wrd.13 for <48463@debbugs.gnu.org>; Fri, 01 Oct 2021 08:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=zB32dqjLJea/F6jn91kirfvJMpwkXj6tIui7Vbp54y4=; b=eO0EiPd3LFJJC31a39livAfIvsBye+1Pk9O17yFeFm5GYOt9vk25LyrLhdtNrhFKZr 41oLQI+YR/NR0CG6/73Nimhxf8W+ljxVK6rhn89bDG65eN51BTWgGrJRNEl3OpYbidHa qmRk9DL+MGiNifYZgd7cp58HI2KFTWVU9E+gEnK9ehuDlOZuUv7ZkJXrNdeP0j5CXvOi 1JBiX/goqZVajmxQzyAbIx29ImYIGyv/7bXvscynh7iG642iihyFA99dlQq9ZvxzuCt1 n4VP9WDZJQ8LIC59I5quLCiOrMooDBt82Pwu1kmMleE0d6pshHVxuj8c0GPzt8Y7WAdT WT7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=zB32dqjLJea/F6jn91kirfvJMpwkXj6tIui7Vbp54y4=; b=4ZJgd+330fBVjdxXx0vinFLv5DdG5VuHp38jC11L+/6stcJ8xTfi0ohP99gQvdDgjB qTFODC1XG2YVGztSydkWNrIoJWW1TV4R/ayEaUELz4sOvnCagxgg2/DgulXi69m3MYjB o3RSPXQ1yHOUOPXwalLbQrTRmzlRqzDvwPpMAyqqkKB3RYjERe/+0nEcVuuVewChsgFJ Bok9V7DpBUvwLYrSq3MeSDWX7j9OAQy2B+hiaeoscnPp3s+633A6cMqdisXScmXYe6C0 si4MUehPl6fTw4xZd8Opo62v7zUCh2CGuhixNJYdOFwguzSWe7wqCgtDV837Q6A5WHbo khCg== X-Gm-Message-State: AOAM532Jas766hkQvchpwVW8En2pQOaw/1CHtugopRbegGAbtMxl01sJ QLL+LpWL9E6mCp8qxJlGShU= X-Google-Smtp-Source: ABdhPJy434Cq4zKHuv8ru1sBD6di9H/CMoyhcRaYiyS7ZiUoN77GwkwHN77KpHxGjf7luq1X6QM19A== X-Received: by 2002:adf:97d4:: with SMTP id t20mr6590488wrb.34.1633102273590; Fri, 01 Oct 2021 08:31:13 -0700 (PDT) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id g12sm8598669wmh.36.2021.10.01.08.31.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Oct 2021 08:31:13 -0700 (PDT) Message-ID: <94f4625dcb0479d873cf60449631527e841fd457.camel@gmail.com> From: Liliana Marie Prikler Date: Fri, 01 Oct 2021 17:31:11 +0200 In-Reply-To: <27DCD25Y68ZWJ.2HRC4G65PWIA7@wilsonb.com> References: <3LOAUDT0FLL4U.2SOD925YP915T@wilsonb.com> <8b853d0585505ce29c9afc638b644fa34805e6c0.camel@student.tugraz.at> <293L8YPQS4CLB.3VK1B1A36XNAY@wilsonb.com> <5d30160bd2a4592459cd407f99cbd3edadb1db1b.camel@student.tugraz.at> <27DCD25Y68ZWJ.2HRC4G65PWIA7@wilsonb.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1633102343; 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:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=zB32dqjLJea/F6jn91kirfvJMpwkXj6tIui7Vbp54y4=; b=OZPX/QiI9HGFaXFMcv1Kuutz76WZix+LPZiLeW/tlbFoSVwaAzuVC+JuN60Q09ih+GjCch Yy9MITjW55LmeM+ud/lYCtsuLasXKdI1hRyM5gzA4jp6Q8R+HyquJOUvHolle+JwAvEruP gmw6x6dHzRIJv+OdJbySrDoCikIColdnmBvMcVptjXveMYQW4i0qwrG8kobMi9zfeQ8k1K oAB6N5fhayaTeRnCmkTVjjvRtSgS6TV0KF36mU/FvdYpkmSluM0FD4+4uQGfjcFi6wlMrY dcxDEQpaRJgiM2qYECeclSSt+pheQwpFWypMbgC5R7ffix82YKcnllCv6O+yuA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1633102343; a=rsa-sha256; cv=none; b=Nkc7QHFZXzppcAyDtOba+jQ1C52dbsYUcSDrmS56a4ngYnoMtQDdPD3GH/d5oMQcoTudRY hFJ7gmIdHBZlVa0HbE66CQ/eAeeA/slbRfEjQfl84qzGYajl+NyGCQKxSxY4F8XtIsn+BZ wASsNJg9I/fb6mt9do32PYthecTAznPDZzs51rIEfPPGG3IpJt/vsFP0193sFgn4qIh/JU FmPpGlAGe64UnokyZca7K/o5EQoK/Bz+GtNURjeXZruMdsSLeurfXSdPGtN/Cp8LnF6gtQ MD2Fk3ita8kX7RDizMEpzbtwbfAxdHmOCv4AXRm+6KQ3csTVu8Tr30yOQ+OJ/g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=eO0EiPd3; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Spam-Score: -1.70 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=eO0EiPd3; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: 04A21EBE8 X-Spam-Score: -1.70 X-Migadu-Scanner: scn1.migadu.com X-TUID: 236Ugms5b/J6 Hi, Am Dienstag, den 25.05.2021, 12:57 +0900 schrieb elaexuotee@wilsonb.com: > As always, thanks for the quick turnaround. > > Leo Prikler wrote: > > stuff-union usually implies, that stuff can't just be put into a > > profile and expected to work (like texlive), whereas in other cases > > (e.g. the gnome metapackage) people can use its parts on their own > > provided that they have the right combination (which typically > > implies having icons etc.) > > Oh, okay. For some reason, I was just imagining "metapackage" to > mean "all batteries included", but your description makes a lot more > sense. In this case, having addons without the J interpreter is > pretty useless, so IIUC a jsoftware-union makes more sense than a > metapackage in this case? > > Just to be clear, J looks for addons at a path burned into > $store/...-jlib-$version/etc/j/profilex.ijs. Currently, that points > to $HOME/.j/$jversion/addons, but we'll need to change that to a > single store output path that contains the union of all desired > addons, hence why I was thinking the *-union approach is needed. > > For now, instead of messing with the union, would it make sense to > just create a (non-public?) jsoftware-addons package that contains > all addons and point jlib at those? Are those addons data packages or can they be compiled without needing jlib? If they're pure data, then you can pack them up and refer them as you wanted to, if not, you first have to create jlib-minimal without them, then package up everything and finally do jlib. Oh, and one thing that was previously ignored is that using XDG standards for things we can't simply put in the store (like configuration if it needs that) is preferable to having a ~/.j directory. > > That's less than the number of Rust versions we need just for > > bootstrap, but still a few too many in my opinion. Are all of > > those still used in production or would it be wiser to to put some > > of them into Guix-Past [1]? > > Oh cool. Guix Past might be a better solution! Thanks for sharing. > > I don't have any solid data, since "in production" J is mostly > dominated by the financial sector from what I hear, but just going by > my impression from lurking on the J mailing list, the j80x series > (and even earlier non-free versions) does still have a user base. > > Personally, I just want to make these older versions available to the > community but am agnostic about the *how* so will defer to whatever > you (and others) think is best. People are also still running ancient versions of Debian. Python 2 has officially reached end of life, yet it is used as well. At some point we do have to declare software that people are still using as old :) > > Having keyword lists is also nice and declarative, but more > > importantly, it lets you call the function as a normal function > > without having to worry about constructing some record in a > > particular way. The configuration you're using doesn't have a > > specific setting? Just override it with your own. It's as simple > > as calling (append old-config extra-config). > > Oh! (append old-config extra-config) is exactly the kind of thing I > was trying > to achieve; however, I'm not sure I quite grok the usage you are > describing. > Something like this? > > (define* (proc #:key foo bar) ...) > (define old-config '(#:foo 0)) > (define extra-config '(#:bar 1)) > (apply proc (append old-config extra-config)) Yup. > > I find this way of mistreating the version field very > > weird. You're not adding anything new by doing this and you're not > > making anything more secure (I'd argue, that it's less secure, > > because you could update the version and forget about the property > > or vice versa). > > I agree the version stuff is a bit crappy. It's something that got > munged badly over time and deserves more thought. Here are the > issues I'm trying to solve: > > 1) The source URLs look like ../j-- or > ../j-, where is either "beta" or > "release", and > depending on whether a patch-level exists; > 2) The type string ("release" or "beta") is a build setting; and > 3) ijconsole installs to something like ../bin/ijconsole-902, > without > including the patch-level, like ../bin/ijconsole-902-b. > 4) Users should probably be able to easily install the latest J > release as > well as J beta concurrently without caring about exactly which > version > these are. > > Those imply that , , and are indeed handled > separately, no matter concrete method utilized. Those four issues do call for separate keyword arguments, but they need not necessarily be reflected in the version string. You can have two packages with the same version, but different hashes in Guix. > My thinking was that 4 means we want a separate *-beta package, > meaning that the version field should probably just look like > "-". > Additionally, relating back to the above discussion about multiple > versions Sounds good, though . would be equally acceptable. Your call. > 5) It would be nice to be able to install the latest j901 without > having to > know that this corresponds to patch level f, i.e. currently > j@901-f. I think `guix build j@901' ought to resolve this automatically. > > First of all, do you even need all this info? `j' is an > > objectively bad name > > for a package. `j-beta' is not better in any way, it only avoids > > the user installing a potentially unstable "J" package. > > Yeah, "j" is pretty short but it does mirror "r". I'm agnostic about > package name, though. Suggestions welcome. Fair enough, though this remains a problem for single letter programs in which others would likely want to claim the letter as well. R has the benefit of being old and well-known enough, it would probably be rlang otherwise (not to be confused with erlang). > > (Note, that we typically use "-next" for that, however). > > Thanks for pointing out this convention. > > > However, this info is meaningless when hardcoded into a > > procedure. You can just inherit from the package that's generated > > and override the name as needed. > > I see what you mean in a general sense but not quite how to apply it > in this case. I am all ears if you have a simpler, cleaner solution > that addresses the constraints listed above! I think the cleaner solution here is to not store those properties in the package, but still having them as parameters to the make-j function call. > > Next, should ijconsole not simply be a package like jlib (both > > properly prefixed with jsoftware- of course)? > > This is effectively what make-j does, no? ijconsole needs to know the > path to jlib, so make-j points it at the correct one and wraps > everything up into a package. I don't really understand why those needs to be done in two steps however. ijconsole could already contain the fully functioning j program. Or partially functioning if we account for addons. Cheers!