I have python2.7, python3.5, and python (which links to 2.7) on my linux machine. Will mach build sort this out and know which version to use for what?
That is the recommend binary naming convention for Python binaries. The build system will (and currently does) sort this out. There may be a few random scripts that don't do things correctly. But `mach` and `configure` should do the right thing. If they don't, it is a bug.
Also, on OS X I only have 2.7, so I assume I'll have to install 3.x using port. What variable do I need to set in my mozconfig to tell mach build where to find 3.x? eg, PY3=/opt/local/bin/python3.5 or something like that?
The build system is smart enough to look in PATH to find an appropriate Python 3 binary. If you want to point configure to an explicit binary, use the PYTHON3 environment variable. From a mozconfig:
Configure's output will print the path and version of any discovered Python 3.5+ binary. You can also look for PYTHON3 in objdir/config.status.
On Sun, Nov 12, 2017, at 12:12 PM, David Burns wrote:
I am not saying it should but if we have a requirement for python 3, we are also going to have a requirement for py2 to both be available for local development.
Correct, and as far as I know that's the plan of record. As Greg said, we're not going to convert all the code in the tree to run under Python 3 immediately, and we will likely have some laggards that stay on Python 2 for a while. We do have folks working on making the in-tree Python code Python 3 compatible (thanks ahal for leading that effort!), so hopefully we could get to a point where Python 3 is used for most things but it's a fair amount of work.
We'd simply like to have Python 3 available for some code that would benefit from its faster execution speed and things like asyncio. Greg floated the idea of doing moz.build evaluation in Python 3 last week, which seems like a great candidate.
Yes, the plan is to require Python 2.7 *and* Python 3 for an indeterminate amount of time. There's absolutely no way we can do a flag day conversion of all the Python in the repo. Unless we make porting an organizational priority (which I don't foresee happening because there is little to gain from touching code not under active development), porting will take years and will likely extend beyond 2020.
What we can do is enable people to write new code targeting Python 3 and port existing code that would benefit from Python 3. That's my main goal for establishing this requirement.