From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id DAE8D158086 for ; Tue, 11 Jan 2022 20:10:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A25FF2BC04F; Tue, 11 Jan 2022 20:10:51 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E2C0D2BC03C for ; Tue, 11 Jan 2022 20:10:50 +0000 (UTC) Message-ID: Subject: Re: [gentoo-dev] Looking for a solution to the distutils/setuptools .egg-info mess From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Tue, 11 Jan 2022 21:10:46 +0100 In-Reply-To: <5494321.44csPzL39Z@pinacolada> References: <908ab66e71703930054cdbfd1cf63eb888ea35e2.camel@gentoo.org> <5494321.44csPzL39Z@pinacolada> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.3 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: 80ca3549-bbb4-489c-84e3-d59a41ecb264 X-Archives-Hash: 5b6cdb4962497f8dc192121b141e1a2e On Tue, 2022-01-11 at 19:23 +0100, Andreas K. Huettel wrote: > > > > TL;DR: how to deal with setuptools (and newer distutils vendored by > > setuptools) replacing .egg-info files with directories? > > > I should probably emphasize here that the .egg-info path contains > > the package version, so this is a problem only if the same upstream > > version is being reinstalled. > > > > You can easily reproduce the problem by playing with: > > > >   SETUPTOOLS_USE_DISTUTILS=stdlib > >   SETUPTOOLS_USE_DISTUTILS=local # vendored > > > 2. We could control the distutils version in ebuilds directly, > > i.e. force "stdlib" for the current versions and have developers > > switch > > to "local" on version bumps. Combined with 1., this will probably > > increase the coverage a bit but dead packages will remain in the > > way. > > It also relies on all devs understanding the problem. > > How about switching it with a new Python version? > (since that is also in the path...) > I'm afraid upstream is likely to drop support for stdlib distutils before we manage to deprecate all the old versions... or even before 3.11 comes out. -- Best regards, Michał Górny