From nobody Fri Jun 03 23:02:18 2022 X-Original-To: python@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D54441BEF703; Fri, 3 Jun 2022 23:02:35 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LFJLY6tGLz57xD; Fri, 3 Jun 2022 23:02:29 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by mail-pl1-x632.google.com with SMTP id w3so7757208plp.13; Fri, 03 Jun 2022 16:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:reply-to:subject:to :cc:references:content-language:from:in-reply-to :content-transfer-encoding; bh=Wr9RW2g8GYmmE01EC1j5esFCssEfQH9o6UzE13O8z1U=; b=j5Py9nhb7jMEcgU18s0P9BQTxDwR9dwl3LR6BJ+bZxhfE+StUd/6K5tXjhr1AopM00 pfJ/Yy4vvGBW2NXm2lSigW11bi1rRCVmwP2WHJVqg/9H01M+7kV5EddUmjVPW0qj7tQf vUcfJBivxwlGRdTwa7SK22Wj/DQ8Lf5YTPIPIcWSZWTDoEXxsznFpb/Oi5dOpZq+y/aI a50BFLPybwQmKdSUS0W87Xacu2lZaWaqh9n0Ypnax6bYnDnNkCTtfFMfeStWcFFsxjcE I7tawDkBcEpPyLBuzTFj6kCFpdD/kqlyVEY2oL8VCADNmZ/Dv/+g6jgngUPO8M4vdNtj xYdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :reply-to:subject:to:cc:references:content-language:from:in-reply-to :content-transfer-encoding; bh=Wr9RW2g8GYmmE01EC1j5esFCssEfQH9o6UzE13O8z1U=; b=iIewgtN0YMqfEgOVawlvU5qdCGkyauR5scRrE1iUqoP7y/sa89CenJ7wZYAqUYgFXL hl9vSyTBxEQMUlAPzorIexS2RfqDynpqmbZoRALJV3oHUpD9W7uxLIlCg8ZJe5hJXOiv A7m+CY/IhIbBekPTFn1GPBIvmxwG3Pf7dS3q0EdmaKq9shPYvUIJZS2ZxK+N9kTMDfP4 P4cSnJeNsEx8nushfbSBw8mNcncPh9BNCy8tOTB/OJIjzk9pOAyYCwwttthnteLkIpyh NH6cDn7AzVA244ciVoRQoxcUNxhGjHoiMLMxfcD02oSQ1mnFf7qPIXCJl3hsT3dLJDZ/ XswA== X-Gm-Message-State: AOAM532lrqFjM5FHqQCslFnABck4XxlRFgcmZ3l8YiKlL0yJMyEwiklN gNd0TjxoLVlPOOGpk1efu28= X-Google-Smtp-Source: ABdhPJyEZFVfW66WnLURH7Z35L91+I45WY3VrVJJrVGeJNTuD2u+OgNwvbtWf849Gln50rbLJbrjyg== X-Received: by 2002:a17:903:41d1:b0:166:3c6:f055 with SMTP id u17-20020a17090341d100b0016603c6f055mr12270163ple.112.1654297343237; Fri, 03 Jun 2022 16:02:23 -0700 (PDT) Received: from ?IPV6:2403:5807:1b:1:6c9e:b489:476f:91c0? (2403-5807-1b-1-6c9e-b489-476f-91c0.ip6.aussiebb.net. [2403:5807:1b:1:6c9e:b489:476f:91c0]) by smtp.gmail.com with ESMTPSA id t5-20020a170902e84500b00163ffe73300sm6079649plg.137.2022.06.03.16.02.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Jun 2022 16:02:22 -0700 (PDT) Message-ID: <97e227bf-09f9-c563-6626-9354c49fca64@FreeBSD.org> Date: Sat, 4 Jun 2022 09:02:18 +1000 List-Id: FreeBSD-specific Python issues List-Archive: https://lists.freebsd.org/archives/freebsd-python List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-python@freebsd.org X-BeenThere: freebsd-python@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Thunderbird/103.0a1 Reply-To: koobs@FreeBSD.org Subject: Re: unknown flavor py37 To: Tatsuki Makino , Chris Cc: freebsd-ports , python References: <2A99B1E9-BAEC-463D-B933-1ED5F09763E5@cs.huji.ac.il> <73DBCA36-27D4-4BF0-9D04-D859316D0C8E@cs.huji.ac.il> <350ac74130b6aa98eaed716a3b5e9679@bsdforge.com> Content-Language: en-US From: Kubilay Kocak In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4LFJLY6tGLz57xD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=j5Py9nhb; dmarc=none; spf=pass (mx1.freebsd.org: domain of koobsfreebsd@gmail.com designates 2607:f8b0:4864:20::632 as permitted sender) smtp.mailfrom=koobsfreebsd@gmail.com X-Spamd-Result: default: False [-1.32 / 15.00]; HAS_REPLYTO(0.00)[koobs@FreeBSD.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_TO(0.00)[hotmail.com,bsdforge.com]; FORGED_SENDER(0.30)[koobs@FreeBSD.org,koobsfreebsd@gmail.com]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FROM_NEQ_ENVFROM(0.00)[koobs@FreeBSD.org,koobsfreebsd@gmail.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.88)[0.878]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2607:f8b0:4864:20::632:server fail,2403:5807:1b:1:6c9e:b489:476f:91c0:query timed out]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::632:from]; MLMMJ_DEST(0.00)[ports,python]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 3/06/2022 2:42 pm, Tatsuki Makino wrote: > Sorry, this email was delivered to my junk folder. > I just pulled this up now :) > > Chris wrote on 2022/05/28 14:25: >> I just bumped into this problem after checking out a fresh ports tree and building >> a port that dependant on devel/py-doit. It complained much the same as above. required >> my performing the build with: >> >> $ make -DBUILD_ALL_PYTHON_FLAVORS ... >> >> So this just seems wrong. python-37 was already installed and is also still present >> in a current version of the ports tree. I know some recent changes were made in ports/Mk >> and I think something may have not been changed correctly. >> >> Just thought I'd mention it. >> >> Chris > > Some py-* ports may be USES=python:3.8+, so such ports will fail FLAVOR=py37. > devel/py-doit fails because it has USES=python:3.8+. > > FLAVOR=py37 of multimedia/openshot > env BUILD_ALL_PYTHON_FLAVORS=1 make -C /usr/ports/multimedia/openshot FLAVOR=py37 build > cannot get to the point of starting the build because devel/py-qt5-pyqt has USES=python:3.8+. > > Regards. > > BUILD_ALL_PYTHON_FLAVORS was implemented in the reverse of what it should have been (DONT_BUILD_ALL_PYTHON_FLAVORS or other). It was implemented ostensibly as a convenience for poudriere, such that the default was for poudriere *not* build all possible supported Python package flavours. The net effect however, was/is: 1) The burden implicitly shifted to everyone else needing to opt into BUILD_ALL_PYTHON_FLAVORS, when the default ought to have been a port builds any supported, available or installed Python version, derived as the intersection of the ports USES=python:, DEFAULT_VERSION value, and what a user has installed, if any any. 2) It forced ports to depend on and match, *exactly*, the of all of their dependencies, otherwise causing "bulk -a" errors [1], even when ports supported Python versions were a *superset* of their underlying dependents supported versions. This resulted in Python ports being incorrectly updated [1], limiting user choice of Python version support, reversing a goal and progress the Python team has had to more correctly, completely and declaratively, and eventually automatically, specify supported Python versions. 3) A substantial reduction in the UX, and increase in the support overhead, for Python packaging and use on FreeBSD, examples being the "errors" above. What needs to happen from here: - The BUILD_ALL_PYTHON_FLAVORS option needs to go away. Before that can happen... - Poudriere needs the ability to only build a single flavor package (not all flavors) without requiring the ports default to be only one. This might take the form of some notion of 'default flavor' (derived from default_version), or something else. Python is happy to help figure out a good way forward on this. - Python ports should not be required to limit or change their supported Python version , to incorrect or unnecessarily constrained values in order to 'unbreak bulk -a' [1]. bulk -a or the underlying dependency resolution mechanism or metadata (in ports, poudriere, or both), should be fixed/improved. Again, Python is happy to help figure out a good way forward on this. [1] https://cgit.freebsd.org/ports/log/?qt=grep&q=unbreak+bulk