-
Notifications
You must be signed in to change notification settings - Fork 36
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
request more detail in 'sympref diagnose' #1009
Comments
You mean you'd like Just clarifying, at first glance it looked like you were asking if you could "provide" the full path to a Python of your choosing, which yes you can. |
See also #1008 I opened for a slightly different troubleshooting idea. |
Yes, I'd like the sympref diagnose to show the python path that is being used. I was trying do this with python itself. For example, to get the module info:
I couldn't get a working snippet that would output the detail though.. |
Here's the snippet that should do it:
|
In OctSymPy terms, that would be
Would you like to work on PR to add this info to |
...POSIX environment when using non-Pythonic IPC. Partially fixes gnu-octave#1009. * inst/private/assert_have_python_and_sympy.m: Update it.
Hello:
This is opened in reference to this thread: https://octave.1599824.n4.nabble.com/Octave-unable-to-find-python-when-using-symbolic-toolbox-tt4695912.html#a4695924
To assist with troubleshooting, is it possible to provide the full path to the python binary that is being used? I use Python virtualenv and run Octave either from the host installation (e.g., dnf install octave, apt install octave) or via Snaps or Flatpaks. Teasing out which Python is actually being called can help troubleshoot various issues.
Thanks and best regards,
Kwan
The text was updated successfully, but these errors were encountered: