From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lucy.dinwoodie.org (b.8.0.0.8.9.b.0.2.f.0.9.2.a.d.b.d.a.0.2.5.1.e.d.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:de15:20ad:bda2:90f2:b98:8b]) by sourceware.org (Postfix) with ESMTPS id B122B3858D28 for ; Sun, 20 Feb 2022 16:29:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B122B3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dinwoodie.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dinwoodie.org Received: from adam by lucy.dinwoodie.org with local (Exim 4.94.2) (envelope-from ) id 1nLp5x-001HqS-GM for cygwin@cygwin.com; Sun, 20 Feb 2022 16:29:57 +0000 Date: Sun, 20 Feb 2022 16:29:57 +0000 From: Adam Dinwoodie To: cygwin@cygwin.com Subject: Re: Inconsistent handling of python3-module vs python3x-module packages Message-ID: <20220220162957.rpeepr2kppc4zvcu@lucy.dinwoodie.org> References: <20220216111059.ve7myugtwi7bjggb@lucy.dinwoodie.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, PDS_RDNS_DYNAMIC_FP, RDNS_DYNAMIC, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2022 16:30:01 -0000 On Thu, Feb 17, 2022 at 03:42:56PM +0000, Jon Turney wrote: > On 16/02/2022 11:45, marco atzeri wrote: > > On Wed, Feb 16, 2022 at 12:11 PM Adam Dinwoodie wrote: > > > > > > While wrangling a bunch of Python packages for my Cygwin installation, > > > I've noticed an inconsistency about how python3 vs python3x packages are > > > installed. > > > > Only one ? ;-) > > > > > As an example: the python3 package itself describes itself as a > > > meta-package; the package itself is almost empty, and the key thing > > > selecting the package does is depend on the latest python3x package, > > > currently python39. The same behaviour is in place with, for example, > > > python3-tkinter. > > > > Yes, these are real meta packages that pull the latest version > > > > > However the python3-pytest package is marked as obsolete, and is > > > obsoleted by python36-pytest. If I select python3-pytest for > > > installation, the package that's actually installed is python36-pytest, > > > even though there's a python39-pytest package available. > > > > > > This inconsistency means that someone naively installing python3-tkinter > > > and python3-pytest will end up with both python3.9 and python3.6 > > > installed, with neither installation having access to both the pytest > > > and tkinter modules. > > > > This is an artifact of of cygport creating python3-xxxx packages > > also for packages that never had a real package called like that. > > We had a discussion if it was worth to make the python3-xxxx pulling the > > python39-xxxx instead of python39-xxxx and it was decided against it. > > I think this is more the emergent behaviour due to various changes than the > result of a considered decision. My assumption here was that this was emergent behaviour, which is clearly not to say there wasn't a discussion at the time about whether it was worth finding a better solution. My hope here is to think about what would be necessary to improve things, not least because this is causing me (admittedly very minor) pain now. > > > I think this inconsistency is liable to cause confusion; it certainly > > > confused me until I worked out what was going on. In my ideal world, > > > we'd be in a situation where I could specify `python3-foo` to an install > > > script and it'd automatically pick up the latest Python version > > > available; I could specify `python3x-foo` if I wanted a specific older > > > release. But at the very least, I'd really like to see these packages > > > being handled consistently one way or another. > > > > I expect no one looking for a package will look for obsolete packages. > > It makes 'install python3-foo' a moving target for scripts. Exactly this. By default, I'd set up packages I maintain that require Python packages -- for both build-time and run-time dependencies -- to look for the latest and greatest Python interpreter and Pyhton modules, and only pin to a specific Python version where there's a clear reason to do so. At the moment I can do that with the python3 package, but not with python3-pytest. Most users are probably not looking at obsolete packages, but if you're trying to automate things by calling setup with the -P option, whether the package you're looking at is marked as obsolete or not doesn't actually get considered. Running `setup.exe -P python3,python3-pytest` seems reasonable, but will hit the problems I've described above. > Patches to cygport to make this work better welcome! I _think_ most -- if not all -- the cygport infrastructure is already in place: cygport clearly already supports both virtual packages and "provides" listings, which are the only bits of this that I think are actually necessary. The difficult part is just either (a) updating the cygport files for all the packages that would benefit, or (b) finding a way to have cygport work out that this is something it should do automatically. I'll have a look at some of the existing cygport files, and cygport itself, and see if I can work out what it would take...