From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id OLS3JP8P02HhxAAAgWs5BA (envelope-from ) for ; Mon, 03 Jan 2022 16:02:23 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id qBNZHf8P02GFUAEAG6o9tA (envelope-from ) for ; Mon, 03 Jan 2022 16:02:23 +0100 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 3FE9E2D808 for ; Mon, 3 Jan 2022 16:02:23 +0100 (CET) Received: from localhost ([::1]:42134 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n4Oqs-0004SD-D4 for larch@yhetil.org; Mon, 03 Jan 2022 10:02:22 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56206) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4OqN-0004QT-CU for guix-devel@gnu.org; Mon, 03 Jan 2022 10:01:52 -0500 Received: from mail2.fsfe.org ([213.95.165.55]:45404) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4OqL-0008OL-Ac; Mon, 03 Jan 2022 10:01:51 -0500 From: Jelle Licht DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fsfe.org; s=2021081301; t=1641222105; 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:references:references; bh=gqvN/Mp1Zq+iWBSTfNSMe0PHQxscWTjZxg0TDRrdJys=; b=cXxVgL7O3kjiejsnChQNMoJvpDwVFiGg1MsnF5hgMoPU8P54V1Nn5opG8NkN+s3kvpAdcb le4ZOnng/hxekIS30wTYiQhXNMjZhtmZaeBtWPho+3AHhhBNLe9yYy/JJ/UJZfdzN3EqjE IiRkKxQntxfUjgr5yWuZ24fbO6mvolY= To: Ludovic =?utf-8?Q?Court=C3=A8s?= , Attila Lendvai Subject: Re: importers and input package lookup In-Reply-To: <87pmp8khla.fsf@gnu.org> References: <87pmp8khla.fsf@gnu.org> Date: Mon, 03 Jan 2022 16:01:43 +0100 Message-ID: <86mtkc3lt4.fsf@fsfe.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=213.95.165.55; envelope-from=jlicht@fsfe.org; helo=mail2.fsfe.org X-Spam_score_int: -1 X-Spam_score: -0.2 X-Spam_bar: / X-Spam_report: (-0.2 / 5.0 requ) DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "guix-devel@gnu.org" 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=1641222143; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=gqvN/Mp1Zq+iWBSTfNSMe0PHQxscWTjZxg0TDRrdJys=; b=D+5XDO/0bMRNaN7vm9uJvUZRBnQewXhcgmaMvlj+424ejGrzU00eIkhiK50Vzaym9JNar0 bkwYgNKhYfGVUhD5Tpd+rypz0vhtiApyT4fD94rS9PkHjVLJoeD5fbIw/1oP1in1YwvT/Y bQjs+HWLvysiCNfjONtxNqXIaosNYWc4cR1eyNQDymqjRYwuZHcv5b25g5QuXrWvDw6x51 QvXbpRygRsv6n87HZyAMwReV+7FXLJ1e+sgcLVLORfAU7UkivplH0wmUPnCu7MBicRGuHW Q/IZ0epWlPHOSmLaMUkreBtXuJ0ScoW0HIxhC/onh62ATNnTLQZrUn72BLVkkg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641222143; a=rsa-sha256; cv=none; b=MdLP6hreiCoN5Nmh8obydJHBoJAVG2RFRfgvDvt4ecy/Tw2qzvlXwbQpNJ+pj20hKfzgmb nDwSj3M74pX29qIjwJ8bZVuyZoBEmhnJ/XKlS/7DrMDO26NZOXmaPfazbLsWAliHNpMzBQ bTnrpq4e4xIC9MRZj4Ze5SimMuFLYnjhYvparQNd1BFVSgwvuNbdcTJrRcAJbUdcKHTrUB 57XdOW9oMYv0VMBMynbdvrW3kijxLI2Yi++xg29XViMXby8t5hUYhYzqKVoN9ASTKNX4bV yTYq95LhIEjPJC2clZtovpHb/N7BqCPG0MwbSPQxd25R1swUFkUGESCaT23Bow== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=fsfe.org header.s=2021081301 header.b=cXxVgL7O; dmarc=pass (policy=none) header.from=fsfe.org; 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: -6.29 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=fsfe.org header.s=2021081301 header.b=cXxVgL7O; dmarc=pass (policy=none) header.from=fsfe.org; 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: 3FE9E2D808 X-Spam-Score: -6.29 X-Migadu-Scanner: scn1.migadu.com X-TUID: 9NMQDsQ/6kGz Ludovic Court=C3=A8s writes: > Hi! > > Attila Lendvai skribis: > >> there are two, independent namespaces: >> 1) the scheme one, and >> 2) the guix package repository. >> >> when i work on an importer (golang), it skips the packages that are alre= ady available in 2), but then it has no clue under what variable name they = are stored in 1), and in which scheme module. > > Does the variable name matters though? In general what matters for the > importer is whether the package/version exists, regardless of the > variable name. Since these packages often end up in a `inputs' list, the variable name seems pretty relevant. >> should the dependency lists in the package forms be emitted as (specific= ation->package "pkgname@0.1.0") forms? > > No, not for packages in Guix proper. > > [...] > >> a bit of a tangent here, and a higher-level perspective, but... shouldn'= t the package definition DSL have support for this? then most package descr= iptions could be using package specifications instead of scheme variables, = and 1) could be phased out. or would that be more error prone? maybe with a= tool that warns for the equivalent of undefined variable warnings? > > Package specs are ambiguous compared to variable references (they depend > on external state, on the set of chosen channels, etc.) so in general we > want to refer to variables. They are pretty explicit at one point in time: the moment we run an importer. So at some point in the course of running the importer, we know we have a package definition somewhere that is pretty much equivalent to the result of (specification->package "pkgname@0.1.0"); can we somehow serialize this package object, perhaps using a heuristic? If someone fiddles with GUIX_PACKAGE_PATH, GUILE_LOAD_PATH or any amount of channels this impacts the result of running an importer, but importers already can give different results depending on these settings.