Drake: binaries: Distribute compiled Python 2+3 packages

[RussTedrake]

~https://drake.mit.edu/python_bindings.html#python-bindings-binary
should be updated to acknowledge official support for Python 3.~

---

EDIT (eric): We should decide on a policy for distributing binaries with Python 3.

Possible solutions:

• Package both Python 2 + 3
  
  
  
  • With #10288, this may make things rather large, but would simplify download interface.
  
  
• Play the combinatorics game, distribute both or a subset.

[EricCousineau-TRI]

Actually, the current docs are correctly worded:

Python 2.7 is currently the only supported version for the bindings supplied by the binary packages.

Changed title to better reflect this. (Have discussed this with Jamie before.)

[jwnimmer-tri]

In the meantime, we could amend that document to say something like "Python 2.7 is currently the only supported version for the bindings supplied by the binary packages. To use Python 3.x, you must compile Drake from source."?

[RussTedrake]

can you help me understand the reason we don’t have python 3 in binaries?

[EricCousineau-TRI]

Just because I didn't capture it in #8352; was in-source support, did not capture / prioritize binary distribution yet (immediate use cases were building from source). Can raise priority on this issue if so desired.

(Sorry about that!)

[jamiesnape]

can you help me understand the reason we don’t have python 3 in binaries?

It's been on my radar. Just waiting on a decision on whether we want to bundle in the same package as Python 2, separate packages, or instead of Python 2.

[jwnimmer-tri]

Having a single binary package seems easier for everyone? Any reason not to (other than file size, which at least Jamie and I agree is not enough of a difference to matter)?

However, I am not sure how easy it would be to implement? It looks like some files under drake/lib/cmake/** (i.e., cps-related details) vary between the python2 and python3 drake installs. It is possible to alter those files so that a single copy can meet all needs, or do we have to install two copies to different paths, or ...?

The *.cmake changes are the only gotchas I see on first glance, but we should probably diff the two installs to track down any additional discrepancies, if we decide to try the single-package route.

[jamiesnape]

The CMake differences are certainly not essential (typically CMake projects would not have those details). Personally I would remove them. It is not difficult for the user to derive the PYTHONPATH and Python version that they are using.

[jamiesnape]

Basically, we can remove:
https://github.com/RobotLocomotion/drake/blob/b9e9c4fa094bfa11872e44ae6e5cc34df510709b/tools/install/libdrake/drake.cps.in#L46-L59
and
https://github.com/RobotLocomotion/drake/blob/b9e9c4fa094bfa11872e44ae6e5cc34df510709b/tools/install/libdrake/drake.cps.in#L120
and everything still works.
The user just has to derive how to set their PYTHONPATH, which is one line of documentation.

[EricCousineau-TRI]

Sounds good to me. Per discussion in #10288 and here, I'm good with us packaging both in the same binary. We could indicate what Python versions the archive contains in the installation docs.

[jwnimmer-tri]

(Trimming back the drake.cps is fine by me. I think the pybind11.cmake also had lots of python details; can we trim that too?)

In any case, I think we can leave it to @jamiesnape to chase down these details in preparing the feature.

[RussTedrake]

Thanks all. I’ll be trying python3 in my class starting feb. the primary distribution is via docker (so could use source), but binaries would be nice.

[jamiesnape]

I think the pybind11.cmake also had lots of python details; can we trim that too?

Should already have happened in https://github.com/RobotLocomotion/drake/commit/dd466e07c82f0d0919ea99868bac909943f0f855.

[EricCousineau-TRI]

Per meeting with Jamie, should be ready by Tuesday.

[jamiesnape]

Current nightly builds have Python 3 bindings. Just needs a minor documentation update in Drake.