-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Comments
Actually, the current docs are correctly worded:
Changed title to better reflect this. (Have discussed this with Jamie before.) |
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."? |
can you help me understand the reason we don’t have python 3 in binaries? |
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!) |
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. |
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 The |
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 |
Basically, we can remove: drake/tools/install/libdrake/drake.cps.in Lines 46 to 59 in b9e9c4f
and drake/tools/install/libdrake/drake.cps.in Line 120 in b9e9c4f
and everything still works. The user just has to derive how to set their PYTHONPATH , which is one line of documentation.
|
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. |
(Trimming back the In any case, I think we can leave it to @jamiesnape to chase down these details in preparing the feature. |
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. |
Should already have happened in dd466e0. |
Per meeting with Jamie, should be ready by Tuesday. |
Current nightly builds have Python 3 bindings. Just needs a minor documentation update in Drake. |
https://drake.mit.edu/python_bindings.html#python-bindings-binaryshould 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:
The text was updated successfully, but these errors were encountered: