Details
-
Type:
Bug
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: Third Party Software
-
Labels:
-
Story Points:0.1
-
Team:Architecture
Description
I have python3.7 installed in /usr/local/bin and my anaconda python is 3.6.5. The anaconda python is the "python" picked up in my PATH but pybind11 cmake detection picks up the version in /usr/local. This does not happen if my anaconda python is also 3.7. Is it possible that the cmake python detection is trying to find the newest python on the path?
I have a patch at https://github.com/lsst/pybind11/tree/u/timj/pythonexe that fixes the problem in our eupspkg.cfg.sh by forcing the python in the path to be the python to use.
Whilst looking at this problem I see these warnings:
Building CXX object tests/CMakeFiles/pybind11_cross_module_tests.dir/pybind11_cross_module_tests.cpp.o
|
[2018-08-19T23:06:20.797837Z] In file included from /Volumes/ExternalSSD/Users/timj/work/lsstsw-classic/build/pybind11/tests/pybind11_cross_module_tests.cpp:10:
|
[2018-08-19T23:06:20.797866Z] In file included from /Volumes/ExternalSSD/Users/timj/work/lsstsw-classic/build/pybind11/tests/pybind11_tests.h:2:
|
[2018-08-19T23:06:20.797869Z] In file included from /Volumes/ExternalSSD/Users/timj/work/lsstsw-classic/build/pybind11/include/pybind11/pybind11.h:43:
|
[2018-08-19T23:06:20.797878Z] In file included from /Volumes/ExternalSSD/Users/timj/work/lsstsw-classic/build/pybind11/include/pybind11/attr.h:13:
|
[2018-08-19T23:06:20.797881Z] In file included from /Volumes/ExternalSSD/Users/timj/work/lsstsw-classic/build/pybind11/include/pybind11/cast.h:16:
|
[2018-08-19T23:06:20.797883Z] /Volumes/ExternalSSD/Users/timj/work/lsstsw-classic/build/pybind11/include/pybind11/detail/internals.h:82:14: warning: 'PyThread_create_key' is deprecated [-Wdeprecated-declarations]
|
[2018-08-19T23:06:20.797894Z] decltype(PyThread_create_key()) tstate = 0; // Usually an int but a long on Cygwin64 with Python 3.x
|
[2018-08-19T23:06:20.797897Z] ^
|
[2018-08-19T23:06:20.797903Z] /usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/include/python3.7m/pythread.h:95:43: note: 'PyThread_create_key' has been explicitly marked deprecated here
|
[2018-08-19T23:06:20.797940Z] PyAPI_FUNC(int) PyThread_create_key(void) Py_DEPRECATED(3.7);
|
[2018-08-19T23:06:20.797949Z] ^
|
[2018-08-19T23:06:20.797960Z] /usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/include/python3.7m/pyport.h:493:54: note: expanded from macro 'Py_DEPRECATED'
|
[2018-08-19T23:06:20.797997Z] #define Py_DEPRECATED(VERSION_UNUSED) __attribute__((__deprecated__))
|
[2018-08-19T23:06:20.798006Z] ^
|
which seem to be something to think about for the future.
Looks good!
That particular deprecation is new in 3.7, and the APIs that are to be used instead are, too. So I think upstream is probably right to continue using the deprecated version until they're ready to end support for 3.6. Hopefully Python won't be in a hurry to drop them.