https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251019
--- Comment #11 from Olivier Certner <olivier.free...@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. _______________________________________________ freebsd-python@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-python To unsubscribe, send any mail to "freebsd-python-unsubscr...@freebsd.org"
