Date: Sat, 12 Dec 2020 15:56:12 +0000 From: bugzilla-noreply@freebsd.org To: python@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-21822-9n1UhojfQm@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-251019-21822@https.bugs.freebsd.org/bugzilla/> References: <bug-251019-21822@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251019 --- 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 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.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-251019-21822-9n1UhojfQm>