[Bug 251019] [NEW PORT] lang/tauthon: Backwards-compatible fork of Python 2.7 interpreter with Python 3.x features

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251019

--- Comment #11 from Olivier Certner <olivier.freebsd at free.fr> ---
(In reply to Chris Hutchinson from comment #10)

I was thinking the same, but this doesn't seem trivial (see second part below).

Unless, your port already has its own specific build and install targets that
do not rely on specifics of Uses/python.mk (e.g., distutils), in which case you
can already use:
BUILD_DEPENDS+=tauthon:lang/tauthon
RUN_DEPENDS+=tauthon:lang/tauthon

Which port are you talking about?


(In reply to Matthias Andree from comment #9)

If we take 'mail/mailman' as an example, it depends on 'dns/py-dnspython',
which itself depends on 'security/py-pycryptodome'. Each one passes PY_FLAVOR
to its dependency. 'dns/py-dnspython' uses the 'concurrent' and 'cython'
python.mk's options, and both dependencies use "distutils" and "autoplist".

Which means that, to convert 'mail/mailman' to use Tauthon, we have at least
the following options:
1. We indeed plug Tauthon into Uses/python.mk, adding particular flavors and
the ability to specify a non-official (not named python*) ports as the
interpreter.
2. We instead duplicate the dependencies so that they use Tauthon, and we copy
and adapt the wheel (python.mk) to at least support the options mentioned
above.

I looked into python.mk and, unless I'm missing something, 1. doesn't seem to
be that difficult, but then there are several things to decide upon (such as,
e.g., whether Tauthon would be used if 2.8 was the version specified or some
other new variable/option should indicate that).

Option 2. seems to go against the very concept of flavors, leading to ports
duplication, as well as code duplication (tauthon.mk).

So I came up with a third possibility: To conditionalize the USES=python or
USES=tauthon in dependencies depending on the passed flavor (whether it starts
with 'py' or, let's say, 'ta'). If this is possible, at least we would not need
to duplicate ports even if we indeed duplicate python.mk into tauthon.mk.

As time goes by I expect that most Python ports will abandon compatibility with
Python 2.7, because they will introduce the use of Python 3 syntax and
features. Maybe these ports would still run under Tauthon with the appropriate
'__future__' imports, but I'm just speculating at this point. And I do not know
if the features backported into Tauthon cover most of uses cases or not (maybe
they do now, but who knows how long this will stay true). So I guess that,
overtime, ports that we need to run under Tauthon will have to be duplicated.
Then, dodging the bullet now may be the better option, if there are not too
many of them.

-- 
You are receiving this mail because:
You are on the CC list for the bug.