Re: unknown flavor py37

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:<version-spec>, 
DEFAULT_VERSION value, and what a user has installed, if any any.

2) It forced ports to depend on and match, *exactly*, the <version-spec> 
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 
<version-specs> 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 <version-specs>, 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