From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id qAPNGNWzzl9vRwAA0tVLHw (envelope-from ) for ; Mon, 07 Dec 2020 22:59: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 mp2 with LMTPS id gH6hFNWzzl80aQAAB5/wlQ (envelope-from ) for ; Mon, 07 Dec 2020 22:59: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 F110994011C for ; Mon, 7 Dec 2020 22:59:32 +0000 (UTC) Received: from localhost ([::1]:42990 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmPTf-0005bC-U4 for larch@yhetil.org; Mon, 07 Dec 2020 17:59:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42892) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmPTS-0005aF-Jx for guix-devel@gnu.org; Mon, 07 Dec 2020 17:59:18 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38712) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmPTS-0001LU-7L; Mon, 07 Dec 2020 17:59:18 -0500 Received: from host-37-191-236-253.lynet.no ([37.191.236.253]:51206 helo=localhost) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kmPTP-0007yQ-Hc; Mon, 07 Dec 2020 17:59:16 -0500 From: Marius Bakke To: Tanguy LE CARROUR , Ludovic =?utf-8?Q?Court?= =?utf-8?Q?=C3=A8s?= Subject: Re: Poetry upgrade and related packages In-Reply-To: <1607331131.vwxmd3587f.astroid@rafflesia.none> References: <87sg8oo2bq.fsf@eauchat.org> <1607003488.tc0yc76x5m.astroid@melmoth.none> <87wnxw45rr.fsf@gnu.org> <1607331131.vwxmd3587f.astroid@rafflesia.none> Date: Mon, 07 Dec 2020 23:59:12 +0100 Message-ID: <87v9dd43zz.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" 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 Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -4.90 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; 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: F110994011C X-Spam-Score: -4.90 X-Migadu-Scanner: ns3122888.ip-94-23-21.eu X-TUID: 3V17tQJMojt8 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tanguy LE CARROUR skriver: > Hi, > > > Excerpts from Ludovic Court=C3=A8s's message of December 5, 2020 4:44 pm: >> Tanguy LE CARROUR skribis: >>=20 >>> It's not yet clear to me how to handle (python) package updates: >>> - when to update; >>> - when not to update; >>> - when to introduce "versionned" (`-x.y` suffix) package definitions; >>> - when to introduce "next" (`/next` suffix) package definitions; >>> - when to remove the two above suffixes; >>> - =E2=80=A6 >>> >>> So I'm looking forward to reading the answers to this thread! :-) >>=20 >> When a change introduces too many rebuilds, the convention is to make >> that change on a branch that will be merged =E2=80=9Clater=E2=80=9D rath= er than on >> =E2=80=98master=E2=80=99; this is bullet 8 here: >>=20 >> https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html > > Thanks for pointing at, but this "just" tells me on which branch to put > the changeset, not which of the above options should be used when a > package needs to be updated. There is no "one size fits all" rule. With rare exceptions, Guix "wants" to have only have a single version of each package (mainly to ease maintenance). As you found, that's not always feasible. If a package depends on a newer version of something "deep in the graph" such as Pytest, it's always OK to add a "/next" or "-x.y" variant (though a convention about which to use would probably be a good idea). If something depends on a *specific* (older) version of Pytest, it's better to try and make it work with the newer version; but failing that, adding a "-x.y" is fine too. Then there are ecosystems such as Go and Rust that have fairly strict semver rules, and require carrying many different versions of the same package. >> Yet, sometimes we want to introduce new versions that people can get in >> their profile, even if the =E2=80=9Cdefault=E2=80=9D one remains the old= er version to >> avoid world rebuilds. > > That's exactly my point! If the default one lags behind, then after some > time, nobody will use it any more and we will have introduced one or more > `-x.y` package definitions! > I would consider it to be a "saner" approach to have the default always > "point" to the latest version, but then we would have to "fix" package > depending on older versions by introducing `-x.y` package definitions > for them. > > Or am I missing something?! You got it right. It might be saner to make the unversioned variable refer to the newest version, but it would often require "pinning" hundreds of packages to the old version to avoid rebuilds. Thus, it's typically more practical to use the "/next" variant until the next rebuild cycle. Again there is no hard rule here, I did such a change for 'libcap' in 9e1f5a263e4f6df4d075901c9b58a56f80c8b452 because only two packages needed to pin the old version. >> One example is GDB: gdb@8 has 1,671 dependents, but we added gdb@10 on >> the side such that =E2=80=9Cguix install gdb=E2=80=9D gives you version = 10. > > The difference here is that it's a package added to a profile, not a > dependency, so `gdb` means the latest available version of GDB, right? > > As you can see, everything is not yet clear to me! Sorry! ^_^' Hope this clears things up a little more. :-) --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQFDBAEBCgAtFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl/Os8APHG1hcml1c0Bn bnUub3JnAAoJEKKgbfKjOlT6NZQH/03LvB/mKlz1ZbRH0QcxTk8cbQrmPM73Y8u/ U4SeLC5WKRYmLuxapWQJTdk9sSPoDW5TcITHUS+Hde3mVn+mTx/bMJ3mxVd03C5J /8CG+gIaSMazQt35EdTh9cGgwMfy3TMB0hfC+0fIPEEWaR+GJWP2joikF0HQe2ry mJRW8RyETMJT+EMkn43e8cKYBtTA3aeOKqCKJVVW0LMGgJzhQhznQW30gz4J2P6K UouPwTxFHaq9OdphMXDZCEjoxhLuaiUUEs81PgXIH1a+YHkXICp36MjG7G6Cr5mz dkyv2IeAl6K/t5bCwDN+KuSuolC6ROs/ohEwlL2TpzTsyMnMTHs= =PYns -----END PGP SIGNATURE----- --=-=-=--