Use Pybind11's find python tool to correctly locate python install information

[Tilix4]

Fixes #813

Link the Issue(s) this Pull Request is related to.

Each PR should link at least one issue, in the form:

Fixes #823

Use one line for each Issue. This allows auto-closing the related issue when the fix is merged.

Added the pybind11 smart tool to find python: https://pybind11.readthedocs.io/en/latest/compiling.html#findpython-mode

On windows: /path/to/blender/python -m pip install wasn't working.

[meshula]

Wow! Fantastic find (so to speak ;) )

[meshula]

It's a relief to see that the fix is so simple, after all the research and experimentation it took to get here!

[Tilix4]

Yes, I'm happy it ends up like this :)

[Tilix4]

Don't forget to merge with squashing to avoid cosmetic commits (I've made the changes into the github's IDE directly and it didn't go perfectly in the first place...)

[meshula]

Just need to clear the checks. Looks like the comment I requested triggered a line length error....! Oh I see you got it already ;)

check-manifest succeeded
13
./setup.py:100:89: E501 line too long (146 > 88 characters)
14
make: *** [Makefile:141: lint] Error 1
15

[codecov-commenter]

Codecov Report

Merging #950 (4f5ed43) into master (3f97807) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #950      +/-   ##
==========================================
- Coverage   85.65%   85.64%   -0.01%     
==========================================
  Files         191      191              
  Lines       18153    18157       +4     
  Branches     2058     2061       +3     
==========================================
+ Hits        15549    15551       +2     
- Misses       2082     2083       +1     
- Partials      522      523       +1     

Flag	Coverage Δ
unittests	85.64% <ø> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
tests/test_serialized_schema.py	92.59% <0.00%> (-7.41%)	⬇️
tests/test_otiod.py	96.77% <0.00%> (ø)
tests/test_otioz.py	97.95% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3f97807...4f5ed43. Read the comment docs.

[ssteinbach]

I edited the title of the PR to reflect what it is doing (to make generating the change notes for the future release easier)

[meshula]

Thanks!

[meshula]

@Tilix4 We've just found a regression. If one creates a python2.7 conda environment, but python 3.8 is the default python in your path, pybind11 now finds the default python 3.8, not the python that is first in the path. In other words, if I build, using python 2.7, pybind11 prefers python 3.8. It looks like a bit more research is required....! Prior to this commit, pybind11 correctly picks the active python 2.7, or 3.8 as appropriate.

[meshula]

Reading the documentation around FindPython in the pybind11 documents is not encouraging - it says things like "with virtualenv/venv support, and Conda support, this tends to find the correct Python version more often than the old system did".

[Tilix4]

@meshula Okay, I'll have a look. First of all I'll try to reproduce the issue.

[Tilix4]

@meshula I'm sorry but I cannot reproduce this issue.

I've installed a 2.7 conda env: https://repo.anaconda.com/archive/Anaconda2-2019.10-Windows-x86_64.exe

I've tested what follows with both python 3.7 and recently (today) installed 3.8:

• In my usual cmd terminal, python targets to the 3.8.
• Running the conda env (base): python correctly targets the 2.7 python and pip install of the current state of master branch correctly installs OTIO to the python 2.7.

If you may provide a how to reproduce it'd be very helpful!

"with virtualenv/venv support, and Conda support, this tends to find the correct Python version more often than the old system did"

Maybe I don't understand this quote correctly but if FindPython is what we are using, it seems to be the appropriate solution.

[meshula]

I did almost the same as you, except the inverse. My conda base is 3.8, and I created a 2.7 env... I deleted my otio27 environment and reconstructed it from scratch, and now the problem does not recur. I'll double check with the user who reported the issue.

Thanks for following up, much appreciated.

[rogernelson]

Hey all, I have am actually having this issue. I have python 3.9 install in my /usr/local directory (on Mac). When I invoke setup.py from the system Python (2.7). I end up with python bindings built for 3.9 in my python 2.7 site packages and the build is not useable. I can confirm that when I remove the PYBIND11_FINDPYTHON option it starts working again.

You can see my full investigation in these Slack threads:
https://academysoftwarefdn.slack.com/archives/CMQ9J4BQC/p1623277067150200
https://academysoftwarefdn.slack.com/archives/CMQ9J4BQC/p1623280454161300

If you want me to run any tests on my machine let me know. I will try seeing if replacing both PYTHON_EXECUTABLE and PYBIND11_FINDPYTHON with PYBIND11_PYTHON_VERSION set to the version of the interpreter than invokes the setup.py script might fix the problem. I am hoping this will work like the findpython option except will match on a particular option.

[rogernelson]

I can confirm that using PYBIND11_PYTHON_VERSION fixes my problem. Would someone in this thread be willing to test if it fixes the original issue too?

You can find my changes here:
https://github.com/rogernelson/OpenTimelineIO/tree/autodesk/nelsonr/python_version