From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 2xW7MJ6sUmFIBwAAgWs5BA (envelope-from ) for ; Tue, 28 Sep 2021 07:48:14 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id qIfCK56sUmH+AgAAbx9fmQ (envelope-from ) for ; Tue, 28 Sep 2021 05:48:14 +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 560A932895 for ; Tue, 28 Sep 2021 07:48:08 +0200 (CEST) Received: from localhost ([::1]:53916 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mV5yJ-00015F-AR for larch@yhetil.org; Tue, 28 Sep 2021 01:48:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58180) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mV5xo-00014r-Jl for guix-devel@gnu.org; Tue, 28 Sep 2021 01:47:36 -0400 Received: from out1.migadu.com ([91.121.223.63]:26549) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mV5xl-0000TX-UY for guix-devel@gnu.org; Tue, 28 Sep 2021 01:47:36 -0400 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mgsn.dev; s=key1; t=1632808051; 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: in-reply-to:in-reply-to; bh=GkQEX3rlxkhdvPnntvs/E7xYQwrWJeZepCgTfFJE3ac=; b=Nnk0cwNITVSBPqvTs9oB5VQnyT4xAxIlTRW2pZDVzMWkFM7oRW67SxTyN5zJKo5ksfvvPi wDiJOb2QxQTzbqCh6nQyUPCZtpRkfp+bkRAZrUpQl9lvPBD1SlK7YwodYg/TvJ7Iu1I4ev l9xBorXHE/y98r2xkB9KqzJn3QMGl+E= From: Sarah Morgensen To: Katherine Cox-Buday Subject: Re: Go importer and packages with version flags In-Reply-To: <87ee99qulr.fsf@gmail.com> (message from Katherine Cox-Buday on Mon, 27 Sep 2021 21:53:04 -0500) Date: Mon, 27 Sep 2021 22:47:28 -0700 Message-ID: <86wnn1tfnz.fsf@mgsn.dev> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=91.121.223.63; envelope-from=iskarian@mgsn.dev; helo=out1.migadu.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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1632808088; 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:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=GkQEX3rlxkhdvPnntvs/E7xYQwrWJeZepCgTfFJE3ac=; b=ISkYQcJScbi+1as8UvCxREqXCuodBFL/JmeTttysI99hyLvK5fy6+5GsEYG3o1HZCd32F3 lNokTklzlQIZmftlTFZjxgD3uXq3mncoiYGWn5tRTg9Ek0DmB/zstYpzpdWyfc/nTnUJ2N jeW3n7HF6ybe5pNE7h8ip5WhoFL/PCByWB4yHlVYVBQj6LRmJlIKXXlSM1eOMtaBQGd9DG 0B6ccxlxw/CSdrYdAnbbED437Dpz/BxET3ODXQsky12lH1cYBF8DWBbahicZ62vCr7jV8X ItbJBhcqG8uvqdAVig5dwUPVa+tl3dxW2kTrlGBk7pdGJC1W01sWJCaAi3hNoA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1632808088; a=rsa-sha256; cv=none; b=AD7CBj3Wbo7CyjYcATmCll/rPvf7qKvm8IVWoWHHrbte2nQzZdEnlFbBl9tnLiMVkj+ETL j8ZuRH2O8LwJ3Cs9s0TDt7eFW8G6hgk0tBL9Gxm8d50EttlKit49RX7AWlnvGtGEN/Uie0 t1QxXx9//hzmcog93/T2o+Iygmwd97UG26LD10SaCBMNe0JVMH2pGXhgv20BWXFIF6fwl+ KssqrtVVfieza9pc4PIOmCYfBCojukIblaeXg07NugXzYIOR3xBPXnqedkisJRiioSrGHT xmwoGhSwVCRm/iJRla2uStEROP/1BLthrOleDedbgCADS/Yrbi5BduEkgGiK7g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=mgsn.dev header.s=key1 header.b=Nnk0cwNI; dmarc=fail reason="SPF not aligned (relaxed)" header.from=mgsn.dev (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -1.79 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=mgsn.dev header.s=key1 header.b=Nnk0cwNI; dmarc=fail reason="SPF not aligned (relaxed)" header.from=mgsn.dev (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 560A932895 X-Spam-Score: -1.79 X-Migadu-Scanner: scn1.migadu.com X-TUID: aeiRsD94ftqb Hi Katherine, Jack, Katherine Cox-Buday writes: > Jack Hill writes: > >> Hi Guix, > > Hey, Jack, a few thoughts. > >> While I was was working with the go importer today, it suggested I package >> go-github-com-russross-blackfriday-v2. Fair enough, except we already have a >> package for go-github-com-russross-blackfriday. > > I was poking around a rust code-base the other day and I noticed our crate > importer, and thus a lot of crate packages, have major-version suffixes. I > think one of the unique benefits of Guix is that it can simultaneously have > multiple versions of libraries installed, and I think we should allow this > for library packages. > > I know that leads to dependency graph explosion, but perhaps we only commit > to substitutes for the latest version, and thus any packages using old > versions. It should converge over time unless packages go unmaintained. > > I thought our current stance was to only allow one version at a time, but > the crate packages made me question this. I'd like clarity too. I think there's a bit of a difference between (our packages for) the Rust and Go ecosystems here. In the Go ecosystem, a module is uniquely identified by its module path, e.g. "github.com/russross/blackfriday/v2". According to Go's major version suffix rules [0], "[s]tarting with major version 2, module paths must have a major version suffix like /v2 that matches the major version." Therefore, each major version is logically a different module according to Go, and so I think we should treat them as separate packages as well. (Note that in many cases we can use 'inherit' for brevity.) Additionally, the major version suffix rules dictate that "[i]f an old package and a new package have the same import path, the new package must be backwards compatible with the old package." Assuming upstream sources follow the rules, we should be able to update each Go package within each major version without breaking dependencies. (A corollary to that is that packages often break if you try to use a v2 when it is expecting a v1.) I think this differs from Rust, where we have, for example, package-0.1 and package-0.2 coexisting. This difference should prevent dependency graph explosion for Go. There are some caveats with "major version suffixes": * Major versions 0 and 1 don't get a version suffix (so no /v1)... * ...except for module paths starting with "gopkg.in/", which always have a major version suffix, but theirs is styled ".v1" rather than "/v1". * Modules may either be located in the repository root, or in a "/v2" subdirectory (for major version 2). This makes things difficult for our importer, because we can't know whether the unpack path should include "/v2" without looking at the repository contents. This is why Jack had to manually add "/v2" to the unpack path. I recently made some changes to the importer to better handle, for example, "github.com/example/repository/subproject", but it doesn't yet discriminate between "/subproject" and "/v2", so it treated "/v2" like a subdirectory of the repository. (Until we fix this properly, the importer should probably not count major version suffixes when calculating the unpack path, since most projects don't use a "/v2" subdirectory.) All that to say... I think we should definitely maintain coexisting Go v2, v3, etc. package definitions. We should probably go the way of Rust though, so we have them all in the same package, at different versions: (define-public go-github-com-russross-blackfriday-v2 (package (name "go-github-com-russross-blackfriday") (version "2.1.0") instead of as different packages: (define-public "go-github-com-russross-blackfriday-v2" (package (name "go-github-com-russross-blackfriday-v2") (version "2.1.0") And of course, it should be policy to remove dependency packages with no dependents. (Perhaps we could write a new linter to warn if a "go-" package has no inheriters and no dependents?) Does that sound reasonable? -- Sarah