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 YPP1C0m2wV9AFQAA0tVLHw (envelope-from ) for ; Sat, 28 Nov 2020 02:30:33 +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 SKfHB0m2wV9WcgAA1q6Kng (envelope-from ) for ; Sat, 28 Nov 2020 02:30:33 +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 AAC83940253 for ; Sat, 28 Nov 2020 02:30:31 +0000 (UTC) Received: from localhost ([::1]:57940 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kiq0M-0002k4-18 for larch@yhetil.org; Fri, 27 Nov 2020 21:30:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56194) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kiq0D-0002ju-49 for help-guix@gnu.org; Fri, 27 Nov 2020 21:30:21 -0500 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:58307) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kiq0B-0008CB-6c for help-guix@gnu.org; Fri, 27 Nov 2020 21:30:20 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5EBC75C013B; Fri, 27 Nov 2020 21:30:17 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 27 Nov 2020 21:30:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=famulari.name; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=mesmtp; bh=+MM2kIQN4x3ejqA2XdEGv3PW fL31arLayTXxGAJga+4=; b=MddD5VjSTZCOyq2QFlbzKmmnXUGb4zgM0r3q37q6 RtkPcykxecs92QavYFXlUVb5pbSqlwvkicITdlacTm9BCMr1cVjoSyYBCg6nBXPq 8hwgBYuuQB7iF/nf3IG2LXI4baE5Ne5Y2zOjDZ4zAEQ8HRxQ8obzBKhzqWf6LgYx eZg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=+MM2kI QN4x3ejqA2XdEGv3PWfL31arLayTXxGAJga+4=; b=fOVSCQPVpkIZma3vG+Pkxt 6xkFr8tV4WlRKb4ZL/NVNoZoJfqeGccPxRwU7o672FGPNG9jyZ2qZuSLI5yduTkW wb8a6l3TflDuVVZ4TcDIHKDgLfGg5zV36vu+EmEOzbfhNC85SQcnz8s1DCId8Oz2 bQbmEHImi/QtuaFn69DayM8Ftpt3cNIWZenZEkMNS0LRbBvqdjmF0E1d9VO0rtRZ TaZw5XHAZRLmedqbukHXDlPBZnGJ/afaWwjKb68tx2UUQqjKUxCenkU6hyJwIQAA Q+ViaES7lIkxmDAsLVkzpKHL3khehypZAMem8aUJgmoH03RUsFTOgcdLk4Q+T3Ug == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudehhedggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomhepnfgvohcuhfgrmhhulhgrrhhiuceolhgvohesfhgrmhhulhgr rhhirdhnrghmvgeqnecuggftrfgrthhtvghrnhepvddvudegffefiedttdfhfedvuefhgf ekieekgeekveetgefhfeetgfegueduffeinecuffhomhgrihhnpehgnhhurdhorhhgnecu kfhppeejfedrudeguddruddvjedrudegieenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehlvghosehfrghmuhhlrghrihdrnhgrmhgv X-ME-Proxy: Received: from localhost (c-73-141-127-146.hsd1.pa.comcast.net [73.141.127.146]) by mail.messagingengine.com (Postfix) with ESMTPA id F28ED3280064; Fri, 27 Nov 2020 21:30:16 -0500 (EST) Date: Fri, 27 Nov 2020 21:30:14 -0500 From: Leo Famulari To: Stephen Scheck Subject: Re: Build determinism, dependency granularity, and dependency scope Message-ID: References: <20201125231554.GD2093@jasmine.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=66.111.4.25; envelope-from=leo@famulari.name; helo=out1-smtp.messagingengine.com 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: help-guix Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: "Help-Guix" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.47 X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=famulari.name header.s=mesmtp header.b=MddD5VjS; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=fOVSCQPV; dmarc=none; spf=pass (aspmx1.migadu.com: domain of help-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=help-guix-bounces@gnu.org X-TUID: S0xNXdcPoOUu On Fri, Nov 27, 2020 at 02:08:19PM -0500, Stephen Scheck wrote: > Java-based Guix packages also suffer from this problem (actually, I'm far > more familiar with dependency management in the JVM landscape than for Go, > but the use of granularly versioned and scoped, distributed dependency > models by both languages appears to be similar on the surface). > > For example, the `java-log4j-core` Guix package (at version 2.4.1 in the > Guix tree) has a dependency on `java-fasterxml-jackson-core` (at version > 2.9.4), but the corresponding Log4j release asserts a dependency version of > 2.6.2 in its `pom.xml` [1]. Yes, sounds quite similar... more room for improvement. > In the case of the Go application I was trying to package, it does not > include vendored dependencies. And I don't have any relationship or > check-in privileges with the project - it is simply something I wanted to > use in an environment with other Guix-sourced packages. Well, I guess it > would be straightforward to fork the GitHub source, run `go mod vendor` [2] > and check in the vendor directory with a specific tag such as > "vx.y.z-guix-vendored". Whether the project maintainers would accept such a > pull request, or if it would be considered bad form to refer to a forked > repository in a Guix package definition instead of the official repo if > not, I don't know. Right, that should work, and would be a good way to get started for a "private" package, but we (Guix) really need to improve our tools here. On that note... I just remembered we have a WIP patch that adds a recursive Go module importer: https://bugs.gnu.org/44178 I encourage you to try it out! I see you have a patch in Guix, so maybe you learned how to apply patches and use the 'pre-inst-env' script to test them, as described in the manual section Contributing? Please don't hesitate to ask for help :) I think the ideal solution is to combine recursive module importing with the "dependency constructor".