python_variants branch report

[Vincent Habchi]

Hi Josh,

I apologise for this *very* belated answer.

> Please don't add a new version of the python portgroup or use a different python.version string for abi3t builds. That will just lead to unnecessary duplication of a lot of modules.

Ok, so, if I understand correctly what you ask for, we keep the python 1.0 PortGroup file, and what’s built for 315t is also valid for 315 because 315t uses a subset of the 315 ABI. Fine. But then we still need a mechanism to set the proper python.runtime, which we cannot know from the subport any more. The installation also needs to be done in the proper Framework folder (3.15 vs 3.15t) and, finally, unless I’m wrong (very likely), no one can install both 3.15 and 3.15t at the same time (extension would be reported as already installed).

> The interface sounds fine. Initial impression is that it's quite a lot of code for what it does. The comments are also very verbose. Please remove the "eval [subst { ..." construct, that's an antipattern.

Ok, I’m going to do this. I apologise for the verbosity. That’s Claude output, not mine. I didn’t bother prune the comments yet, my primary goal was to get something usable. I’m going to refine the code the following days.

>> – A perl_variants 1.0 PortGroup file. Same principle as python_variants, but for perl dependent ports. In this case, there is no ${perl.branch} variable since the variants are spelled with the separating dot (ex.: perl.variants 5.34 5.36 5.38 5.40 5.42). These two new portgroups mimic what FreeBSD port(1) does using mk.conf customisation.
> 
> How does this differ from perl5.create_variants in the perl5 portgroup?

Does that option automatically set all other variables (perl.bin, etc.) to the needed values?

> Great! That will need to be merged to master separately though, and as multiple commits over time so it doesn't overload the buildbot.

Okay, let me know when I can actually start this process.

Cheers,
Vincent