From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id MMAsAepcz18TdgAA0tVLHw (envelope-from ) for ; Tue, 08 Dec 2020 11:00:58 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id GEuCOOlcz1++RAAAbx9fmQ (envelope-from ) for ; Tue, 08 Dec 2020 11:00:57 +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 B55BB94036A for ; Tue, 8 Dec 2020 11:00:57 +0000 (UTC) Received: from localhost ([::1]:33712 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmajo-00053I-J7 for larch@yhetil.org; Tue, 08 Dec 2020 06:00:56 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36660) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmaja-00052H-EX for guix-devel@gnu.org; Tue, 08 Dec 2020 06:00:42 -0500 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:48881) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmajW-0000rh-QN; Tue, 08 Dec 2020 06:00:42 -0500 X-Originating-IP: 176.185.184.238 Received: from localhost (static-176-185-184-238.axione.abo.bbox.fr [176.185.184.238]) (Authenticated sender: tanguy@bioneland.org) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 9E4ADFF808; Tue, 8 Dec 2020 11:00:30 +0000 (UTC) Date: Tue, 08 Dec 2020 12:00:27 +0100 From: Tanguy LE CARROUR Subject: Re: Poetry upgrade and related packages To: Ludovic =?iso-8859-1?q?Court=E8s?= , Marius Bakke References: <87sg8oo2bq.fsf@eauchat.org> <1607003488.tc0yc76x5m.astroid@melmoth.none> <87wnxw45rr.fsf@gnu.org> <1607331131.vwxmd3587f.astroid@rafflesia.none> <87v9dd43zz.fsf@gnu.org> In-Reply-To: <87v9dd43zz.fsf@gnu.org> MIME-Version: 1.0 User-Agent: astroid/0.15.0 (https://github.com/astroidmail/astroid) Message-Id: <1607422279.q306mwrdai.astroid@melmoth.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: none client-ip=217.70.183.199; envelope-from=tanguy@bioneland.org; helo=relay9-d.mail.gandi.net 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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.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: -2.30 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=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: B55BB94036A X-Spam-Score: -2.30 X-Migadu-Scanner: ns3122888.ip-94-23-21.eu X-TUID: +ydrXSuDyOqD Hi Marius, Excerpts from Marius Bakke's message of December 7, 2020 11:59 pm: > Tanguy LE CARROUR skriver: >> 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 rat= her 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.htm= l >> >> 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. >=20 > 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. >=20 > 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. `-x.y` packages are here to stay. `/next` are temporary packages. Is it safe to remove all `-x.y` packages that are not used as inputs? Is there a (programmatic) way to find those packages? When `/next` become "current|default|latest", who is in charge of patching all the package definitions that were using it?! >>> 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 ol= der 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 mor= e >> `-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?! >=20 > 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. Then, during the rebuild cycle those hundreds of packages get rebuilt and=E2=80=A6 some of them fail because they depend on the older version, ri= ght?! But I'm pretty sure it's a problem all distributions have to face. Wasn't it discussed somewhere else that one should get notified (by email) when their favourite packages were broken? > 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. > Hope this clears things up a little more. :-) Yes, thanks! But I guess I need to go through more of those situations to make sure I understand everything. --=20 Tanguy