Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

binaries: Distribute compiled Python 2+3 packages #10408

Closed
RussTedrake opened this issue Jan 15, 2019 · 14 comments
Closed

binaries: Distribute compiled Python 2+3 packages #10408

RussTedrake opened this issue Jan 15, 2019 · 14 comments
Labels

Comments

@RussTedrake
Copy link
Contributor

RussTedrake commented Jan 15, 2019

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:

@EricCousineau-TRI
Copy link
Contributor

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.)

@EricCousineau-TRI EricCousineau-TRI changed the title sphinx docs say "Python 2.7 only" binaries: Decide on policy for distributing compiled Python 3 packages Jan 15, 2019
@EricCousineau-TRI EricCousineau-TRI added component: distribution Nightly binaries, monthly releases, docker, installation configuration: python and removed type: documentation labels Jan 15, 2019
@jwnimmer-tri
Copy link
Collaborator

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."?

@EricCousineau-TRI EricCousineau-TRI changed the title binaries: Decide on policy for distributing compiled Python 3 packages binaries: Distribute compiled Python 3 packages Jan 15, 2019
@RussTedrake
Copy link
Contributor Author

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

@EricCousineau-TRI
Copy link
Contributor

EricCousineau-TRI commented Jan 15, 2019

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
Copy link
Contributor

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
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link
Contributor

Basically, we can remove:

"PythonInterp": {
"Version": "@PYTHON_VERSION@",
"X-CMake-Find-Args": [
"EXACT",
"MODULE"
]
},
"PythonLibs": {
"Version": "@PYTHON_VERSION@",
"X-CMake-Find-Args": [
"EXACT",
"MODULE"
]
},

and
"drake_PYTHON_DIRS": "${CMAKE_CURRENT_LIST_DIR}/../../python@PYTHON_VERSION@/site-packages",

and everything still works.
The user just has to derive how to set their PYTHONPATH, which is one line of documentation.

@EricCousineau-TRI
Copy link
Contributor

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
Copy link
Collaborator

(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
Copy link
Contributor Author

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
Copy link
Contributor

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

Should already have happened in dd466e0.

@EricCousineau-TRI EricCousineau-TRI changed the title binaries: Distribute compiled Python 3 packages binaries: Distribute compiled Python 2+3 packages Jan 17, 2019
@EricCousineau-TRI
Copy link
Contributor

Per meeting with Jamie, should be ready by Tuesday.

@jamiesnape
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants