Date: Sat, 12 Dec 2020 15:56:12 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 251019] [NEW PORT] lang/tauthon: Backwards-compatible fork of Python 2.7 interpreter with Python 3.x features Message-ID: <bug-251019-7788-uzoiV8sUTP@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-251019-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-251019-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D251019 --- Comment #11 from Olivier Certner <olivier.freebsd@free.fr> --- (In reply to Chris Hutchinson from comment #10) I was thinking the same, but this doesn't seem trivial (see second part bel= ow). Unless, your port already has its own specific build and install targets th= at do not rely on specifics of Uses/python.mk (e.g., distutils), in which case= you can already use: BUILD_DEPENDS+=3Dtauthon:lang/tauthon RUN_DEPENDS+=3Dtauthon: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_FLAV= OR 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 c= opy 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 a= s, 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=3Dpython = or USES=3Dtauthon in dependencies depending on the passed flavor (whether it s= tarts 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 appropri= ate '__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 (ma= ybe 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 duplicate= d. Then, dodging the bullet now may be the better option, if there are not too many of them. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-251019-7788-uzoiV8sUTP>