>=www-client/firefox-61 should depend on >=dev-lang/python-3.5. dev-lang/python:2.7 is still required. https://hg.mozilla.org/mozilla-central/rev/eee2776f7c7f "Detect and expose Python 3 to the build system" first release with: 57.0a1 https://hg.mozilla.org/mozilla-central/rev/af5755fcc488 "Require Python 3.5+ to build" first release with: 61.0a1 https://hg.mozilla.org/mozilla-central/rev/1e78f2ccb865 "Find Python 3 in MozillaBuild, require Python 3 everywhere" first release with: 61.0a1 Error without Python 3: 0:05.28 checking for Python 3... : python_wrapper_setup: python3 is not supported by python2.7 (PYTHON_COMPAT) 0:05.28 no 0:05.28 ERROR: Python 3.5 or newer is required to build. Ensure a `python3.x` executable is in your PATH or define PYTHON3 to point to a Python 3.5 executable. 0:05.28 *** Fix above errors and then restart with\ 0:05.28 "/usr/bin/gmake -f client.mk build" 0:05.28 gmake: *** [client.mk:149: configure] Error 1 * ERROR: www-client/firefox-61.0-r1::gentoo failed (configure phase): * (no error message)
Python team: Which solution would you recommend? 1. Inheriting python-any-r1.eclass twice: - Firstly with PYTHON_COMPAT=(python2_7) - Secondly with PYTHON_COMPAT=(python3_5 python3_6 python3_7) (with _PYTHON_ANY_R1 unset...) And calling python-any-r1_pkg_setup() twice. 2. Manually depending on dev-lang/python:2.7[ncurses,sqlite,ssl,threads] and inheriting python-any-r1.eclass only for >=dev-lang/python-3.5.
PYTHON_COMPAT is immutable by design, so don't ever change it. And don't ever hack on eclass internals, this is a guarantee of random failure at a future point. The question is: do you need to use both simultaneously, or are they used at different stages of build? In either case, a major rework of the eclass is required. So the simplest answer is: require sanity from upstream.
A script called by src_configure() checks for both Python 2.7 and >=3.5. Probably both are used by different scripts called by Makefiles during src_compile().
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #1) I would go with option 2. If the configure script looks for /usr/bin/python2.x and /usr/bin/python3.x and only uses it at build time, python-any-r1.eclass isn't really necessary at all. The python3 dependency could be inlined as a static || dep.
Some statistics: In mozilla-central repository currently there are: 102 scripts with '#!/usr/bin/python' shebang 2 scripts with '#!/usr/bin/python2' shebang 1 script with '#!/usr/bin/python2.4' shebang 2 scripts with '#!/usr/bin/python2.5' shebang 2 scripts with '#!/usr/bin/python2.7' shebang 4 scripts with '#!/usr/bin/python3' shebang 1053 scripts with '#!/usr/bin/env python' shebang 8 scripts with '#!/usr/bin/env python2' shebang 1 script with '#!/usr/bin/env python2.4' shebang 5 scripts with '#!/usr/bin/env python2.7' shebang 19 scripts with '#!/usr/bin/env python3' shebang
I don't see much point in supporting py3 to be honest, until such time as py2 can be dropped. Outside of upstream build system developent (which even I try and avoid) there isn't much of a point to using both is there?
Mozilla upstream gives us no choice. Firefox fails to build if no Python >=3.5 executable is found. For now, it might be better to keep PYTHON_COMPAT=(python2_7) and additionally add "|| ( dev-lang/python:3.7 dev-lang/python:3.6 dev-lang/python:3.5 )" to DEPEND. mozcoreconf-v6.eclass will have to be copied to mozcoreconf-v7.eclass with these changes. mozconfig-v6.60.eclass will have to be copied to mozconfig-v6.61.eclass with updated inherit() line.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #7) > Mozilla upstream gives us no choice. > Firefox fails to build if no Python >=3.5 executable is found. > > For now, it might be better to keep PYTHON_COMPAT=(python2_7) and > additionally add "|| ( dev-lang/python:3.7 dev-lang/python:3.6 > dev-lang/python:3.5 )" to DEPEND. > > mozcoreconf-v6.eclass will have to be copied to mozcoreconf-v7.eclass with > these changes. > mozconfig-v6.60.eclass will have to be copied to mozconfig-v6.61.eclass with > updated inherit() line. This makes no sense. Given that py2 is dead and there will be no future releases, it is more reasonable to use the eclass for versions that are actually subject to changes.
I think the worry is that some of those scripts with #!/usr/bin/python or #!/usr/bin/env python shebangs might be called without using the PYTHON2 detected by the configure script. If python_setup sets EPYTHON=pyhton3.x, that would break those scripts. However, it seems very simple to test if that is the case.
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #7) > Mozilla upstream gives us no choice. > Firefox fails to build if no Python >=3.5 executable is found. > > For now, it might be better to keep PYTHON_COMPAT=(python2_7) and > additionally add "|| ( dev-lang/python:3.7 dev-lang/python:3.6 > dev-lang/python:3.5 )" to DEPEND. > > mozcoreconf-v6.eclass will have to be copied to mozcoreconf-v7.eclass with > these changes. > mozconfig-v6.60.eclass will have to be copied to mozconfig-v6.61.eclass with > updated inherit() line. mozconfig*.eclass is going away, so that doesn't apply here. mozcoreconf may need to be adjusted but the python requirements may be pushed into the ebuild there as well. I've done a test locally, and it seems the better option is actually to flip this and use PYTHON_COMPAT=( python3_{5,6} ) in ebuilds, and hard depend on dev-lang/python:2.7 until such time as it's no longer needed upstream. python_export() from the python-utils-r1.eclass lets us set PYTHON and EPYTHON for v2.7 after pushing PYTHON3=${PYTHON} into the environment, and that function doesn't seem to be internal so I think we are safe to use that as-is.
Did you came to a conclusion about this in the meantime? It seems the firefox-62 ebuild pulls in python3, and that the config script checks for python3 as well. But I keep seeing this in htop: python2.7 ./mach build --verbose, python3 used for emerge only.
Current ebuilds are doing it wrong, we are still missing python2 dependency. I don't know yet where the dependencies for > ncurses,sqlite,ssl,threads are coming from but I will try implementing option 2, e.g. > 2. Manually depending on dev-lang/python:2.7[ncurses,sqlite,ssl,threads] and > inheriting python-any-r1.eclass only for >=dev-lang/python-3.5. and see how it works.
Dependencies have been implemented some time ago: $ portageq metadata / ebuild mail-client/thunderbird-68.0-r1::gentoo DEPEND ... dev-lang/python:2.7[ncurses,sqlite,ssl,threads(+)] || ( dev-lang/python:3.7[ncurses,sqlite,ssl,threads(+)] dev-lang/python:3.6[ncurses,sqlite,ssl,threads(+)] dev-lang/python:3.5[ncurses,sqlite,ssl,threads(+)] ) ... $ portageq metadata / ebuild www-client/firefox-68.0.2::gentoo DEPEND ... dev-lang/python:2.7[ncurses,sqlite,ssl,threads(+)] || ( dev-lang/python:3.7[ncurses,sqlite,ssl,threads(+)] dev-lang/python:3.6[ncurses,sqlite,ssl,threads(+)] dev-lang/python:3.5[ncurses,sqlite,ssl,threads(+)] ) ...
https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass/mozcoreconf-v6.eclass?id=ed2ace908b4d5dc23d0f3b873f6d5df867f513d5
