From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id WDAiGanAUWPaWQEAbAwnHQ (envelope-from ) for ; Thu, 20 Oct 2022 23:42:01 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id aDt6GanAUWPvhgAAauVa8A (envelope-from ) for ; Thu, 20 Oct 2022 23:42:01 +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 1031F1C691 for ; Thu, 20 Oct 2022 23:42:01 +0200 (CEST) Received: from localhost ([::1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oldIe-0004bB-76 for larch@yhetil.org; Thu, 20 Oct 2022 17:42:00 -0400 Received: from [::1] (helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oldES-0008UQ-SE for larch@yhetil.org; Thu, 20 Oct 2022 17:37:40 -0400 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 1oldEQ-0008Qm-C5 for guix-devel@gnu.org; Thu, 20 Oct 2022 17:37:38 -0400 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oldEE-00080q-MG for guix-devel@gnu.org; Thu, 20 Oct 2022 17:37:28 -0400 Received: by mail-wr1-x42b.google.com with SMTP id bu30so1543100wrb.8 for ; Thu, 20 Oct 2022 14:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=beadling-co-uk.20210112.gappssmtp.com; s=20210112; h=mime-version:date:message-id:subject:to:from:user-agent:from:to:cc :subject:date:message-id:reply-to; bh=6hO3WlyyhQ03mcWJ3/2U49laoYmNtYDR2jJffzXCwhQ=; b=PJ2ccimXHw0fyYUv9NLCZxxa44+SnUq6UYghb4/7nyLU8b1ieWJRCohrM7oKPESEWK dP2V6fidH7567zP5Qfrliff3zbZOvH2maZJV9U+2eWeKgrwAUCv1GgpLtuTwsBcSGHms f5RXDIye0Nnks+Tf1nn7QhuPEIwX7NKk3aOoGUwejC1IOhbdxN8ZRhru/jQRNYhIP9ML +21KwPOK/HynW9k0X6nEjt+WPP1sp+ppqY0BlvHO+/sGBi7Jb0LOMZAc79T/YssVKQlN PWts4sTHFjRJ1rwzzQSI8A8+yBh4FEdsYSmmdepQMJQ3Ag8KnIJPiC603v2mZHHBkxum GIkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:date:message-id:subject:to:from:user-agent :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6hO3WlyyhQ03mcWJ3/2U49laoYmNtYDR2jJffzXCwhQ=; b=k2Ut31cLvra2y09ZEQ0Jh8DMnY27Cdr9HNSm8vJ5ssU6+2W+GgR5u5ogIOAAuO/f7i B8uvZzFY6LkNloo6OTJBO0aJM0qW5HCLwSP2Z3cA0nEin2o0L0RuJQfrd6am6GLmQTFw +hwTZU6VqRrhDqX1kuNXOHU7p+kHigsXkfdqJA1pwhvaeE5SVqADaIwTUXI38xtor9Mz AfcxCeTde9QP1pFhzUeRlsuiGn1TGofy8Y8oI12qZ7VpKllQ52Rx17oVQUjQRhTrBdO1 kYpzIwB+KBPi/Z9zN7iMloGdP7g/qYoQfESIq3bYJYegCBNk2bLCM3iNIR1U4bR6lWQQ w6dw== X-Gm-Message-State: ACrzQf2d9GasKzhsx3ObhmRw4CAKB+sj4tfg79wDrOhU7z2rTLasnHil 3p4+0h+UVhJaWOeCj6X655q65yqodFBkf4V5 X-Google-Smtp-Source: AMsMyM5b9SsTbcJi4zE+/gp1GIqqN0TcoWjTHR5ziTp0vN6qlRLM+Tm6gVamqXdPFmN3MlIKz0wqRQ== X-Received: by 2002:a5d:47a6:0:b0:22e:7c73:feb2 with SMTP id 6-20020a5d47a6000000b0022e7c73feb2mr10311603wrb.715.1666301842590; Thu, 20 Oct 2022 14:37:22 -0700 (PDT) Received: from xps13 ([2a02:6b61:74a5:0:3e3e:75ff:de88:7a90]) by smtp.gmail.com with ESMTPSA id c1-20020a5d4141000000b002238ea5750csm20985928wrq.72.2022.10.20.14.37.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Oct 2022 14:37:22 -0700 (PDT) User-agent: mu4e 1.4.15; emacs 27.2 From: Phil To: guix-devel@gnu.org Subject: Pinning package inputs using inferiors? Message-ID: <87czam9nxq.fsf@beadling.co.uk> Date: Thu, 20 Oct 2022 22:37:21 +0100 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: none client-ip=2a00:1450:4864:20::42b; envelope-from=phil@beadling.co.uk; helo=mail-wr1-x42b.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 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" 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=1666302121; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=6hO3WlyyhQ03mcWJ3/2U49laoYmNtYDR2jJffzXCwhQ=; b=Ug6YOqnxTMmyrSzc4voOE+DOue+QIA5Z7ulo+LUR26PdMqIgns0//IuW+RnOPByfsuSgwr yVqwtlJiJenB/QWF60jIzkTKwAKOtPmM3TNDj3kPxlXRCrp/DXdNUxIvUUtW9maFCLukWA mm2FuqElj3uE1rS9Rxq/v3KwY+9ChYM6kPHHBr8/p8GGFV62bljezr3Brpau+IRP65Uaz+ d0P8Kq1oIvEGT9eFmdPHlzzMg0143UGaW4MCoJyWnysYEhFmxHbJHzHrXmqe6EgG2AzBjJ Y3UtYg4yxwwZ6p6fVDDHnAVr0YXFtqm4n/rA+j17KX6gzWDfw6DB9FP8MenUcQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1666302121; a=rsa-sha256; cv=none; b=CKgwjvB0icciW5jyLmlDQGk/VEQXV8xdNVmG6E88T+rkjeWrBViLC8MWESk6qBfDLhqTwM YVnYPi1zTTu7mecKkkoDkyvZdJ81wq7msTSvQMlpUgLBUrsoVqPOG3KMoJtX3pgs/eh1Bp VtZfQa8VyYqzMoyJ9hD4hu4vNpj6DbcP7esNRDqv1/Y0HhbCP+XnZnBawqbrIELPczfTnG 520ThSKy/kXGGbeLXHlDF9k96nTXCOQPyvScnyayJrHExIl1zsV5E7sWrGX0Aq2R/sU4pc 62c8TksEdddph9a2pVZkVRGw2DgYEMaCYXzA0NB9duHM1WwX1ZnErzaWT7VpSA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=beadling-co-uk.20210112.gappssmtp.com header.s=20210112 header.b=PJ2ccimX; 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: -2.43 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=beadling-co-uk.20210112.gappssmtp.com header.s=20210112 header.b=PJ2ccimX; 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: 1031F1C691 X-Spam-Score: -2.43 X-Migadu-Scanner: scn1.migadu.com X-TUID: o7Ggc/WnTCZz Hi all, A change in a package ("dependency" in the below example) in a channel I own has caused a conflict in another package in the same channel that depends on it ("test-package" in the below). Whilst fixing the "test-package" package is the right solution, this is too complicated in do in the short-term. I need to pin "dependency" to v1.0 in test-pacakge's propagated-inputs. Simultaneously, other packages need the new update to the "dependency" package to use this functionality to deliver new functionality that can't wait. This isn't a one-off situation; this happens frequently and I'm interested in how other Guixers resolve this with as little friction to users as possible? One brainwave I had was to use inferiors - but this doesn't seem to work. Continuing from the above example we could define access to a historical v1.0 of the dependency package for the test-package like so: (define dependency-inferior ;; An inferior containing dependency v1.0. (inferior-for-channels dependency-channels)) If we do this then I can get the below manifest to work, just like the example in the manual: (packages->manifest (list (specification->package "python") ;; useful for testing ;; Remove current dependency add old dependency (package/inherit test-package (propagated-inputs (modify-inputs (package-propagated-inputs test-package) (delete "dependency")))) (car (lookup-inferior-packages dependency-inferior "dependency" "1.0")))) But this isn't a practical approach - knocking "dependency" out of test-package's inputs means the unit tests would fail, so I would also have to delete the check phase - I don't want to do this, it's too much compromise. Instead I was hoping to replace the dependency *inside* the package definition with an inferior like this, so it's still available whilst the inherited package is being built. (packages->manifest (list (specification->package "python") ;; useful for testing ;; Remove current dependency, add old dependency (package/inherit test-package (propagated-inputs (modify-inputs (package-propagated-inputs test-package) (replace "dependency" (car (lookup-inferior-packages dependency-inferior "dependency" "1.0")))))))) When I try this, depending what operation I perform on the manifest, I normally get some type mismatch telling me I've used a package-inferior when Guile was expecting a package. Nothing works, alas. Thus I'm assuming the two types are not completely substitutable, and this won't work? Given this, the workaround I am employing is to replace a single package definition of "dependency" with locally scoped definitions for each package that uses it. This is duplication feels suboptimal. FWIW, a much more involved solution is to store the dependency package inside test-package's project repo (rather than my channel), and then automate copying this into the channel at build time. This is a cool exercise, but means we are decentralizing the channel's package definitions and co-locating them across many repos - which feels not in the spirit of Guix, and more like how requirements.txt files are co-located in (non-Guix) python projects. My questions are: 1. Is my above use of inferiors always doomed, or something we code make work with changes to Guix core? 2. Is there another way of handling the situation elegantly without using inferiors or duplicating package definitions at module scope. Any advice or comments gladly received! Cheers, Phil.