We Keep Coding

Emacs gud-pdb with miniconda python environments

How does one get emacs to use the same PATH to the python and pdb executables as I get from the term when I have set a specific miniconda environment?
I.e. in emacs, when I run M-x pdb, I would like it to use the same executable as I do if I have done the following from the term:
$ source activate my_py3_env
$ pdb
I know currently this isn't what is happening. I switch to a python 3 env, which modifies my PATH appropriately, but when I run M-x pdb for a python script and print sys.version from within that script I get:
2.7.17 |Anaconda, Inc.| (default, Oct 21 2019, 19:04:46)
So it seems to be picking up the 'base' miniconda env which is still 2.7
I would half of expected it to pick up whats in /usr/bin but that doesn't seem to be the case, i.e. if I execute:
$ /usr/bin/python
I get
Python 2.7.15+ (default, Oct 7 2019, 17:39:04)
To summarise, is there a way to get emacs M-x pdb to 'follow' the conda environment I am currently in without me having to manually specify the location of the pdb executable for each environment?

You can find the conda or virtualenv python path with (swap in the analogous conda equivalent for starting the env):
source .py2james/bin/activate
and
which python in the terminal. Note the path to the python exe.
you can do: option+x pdb
then: /Users/janderson/code/python/awsomeapp/.py2james/bin/python -m pdb main.py and the emacs pdb debugger will start.

Tox not finding python3.6 even with the shim present. What is wrong with my pyenv setup?

Trying to breathe some life back into a django package that has fallen into a state of disrepair. They use tox for testing so I've setup pyenv on my MacBook. I've installed 3 versions of python as you can see below, and everything looks like it should work, but if it was I wouldn't be asking why it is not.
I've replaced my home directory with ~ to make it a bit easier to read.
pyenv was installed with brew install pyenv and the various versions of python were installed with pyenv install #.#.#
The shims exist:
$ echo $PATH
~/.pyenv/shims:~/.platformsh/bin:/usr/local/sbin:...
$ which python3.6
~/.pyenv/shims/python3.6
$ which python3.4
~/.pyenv/shims/python3.4
$ which python3.5
~/.pyenv/shims/python3.5
But executing them does not work as expected:
$ pyenv local 3.4.9 3.5.6 3.6.8
$ python3.4
Python 3.4.9 (default, Feb 12 2019, 10:33:47)
[GCC 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ python3.5
pyenv: python3.5: command not found
The `python3.5' command exists in these Python versions:
3.5.6
$ python3.6
pyenv: python3.6: command not found
The `python3.6' command exists in these Python versions:
3.6.8
And tox fails like this:
py34-1.11: commands succeeded
ERROR: py36-1.11: Error creating virtualenv. Note that some special characters (e.g. ':' and unicode symbols) in paths are not supported by virtualenv. Error details: InvocationError("Failed to get version_info for python3.6: pyenv: python3.6: command not found\n\nThe `python3.6' command exists in these Python versions:\n 3.6.8\n\n", None)
ERROR: py36-2.0: Error creating virtualenv. Note that some special characters (e.g. ':' and unicode symbols) in paths are not supported by virtualenv. Error details: InvocationError("Failed to get version_info for python3.6: pyenv: python3.6: command not found\n\nThe `python3.6' command exists in these Python versions:\n 3.6.8\n\n", None)
py36-latest: commands succeeded
docs: commands succeeded
But in the .tox folder you will find these VirtualEnvs that can be activated manually.
$ ls .tox
dist docs flake8 log py34-1.11 py36-1.11 py36-2.0 py36-latest
Because at some point it was working....
I do understand the mechanics of why it isn't working, what I don't understand is why pyenv is not setting up the environment correctly (Or maybe this is exactly how it is supposed to behave). Everything I read seems to indicate that python3.6 should launch a python3.6.8 interpreter
$ bash -x python3.6
+ set -e
+ '[' -n '' ']'
+ program=python3.6
+ [[ python3.6 = \p\y\t\h\o\n* ]]
+ export PYENV_ROOT=~/.pyenv
+ PYENV_ROOT=~/.pyenv
+ exec /usr/local/Cellar/pyenv/1.2.9/libexec/pyenv exec python3.6
pyenv: python3.6: command not found
The `python3.6' command exists in these Python versions:
3.6.8

pyenv by default picks the python "locally", that is it looks for the PYTHON_VERSION environment variable or a .python-version file.
Personally I find this setup a little cumbersome (needing to have these files littered around all projects, especially in projects which need multiple versions). Fortunately, you can make these "shims" function anywhere with a default version of python by using pyenv global #.#.#
In your case, to make the python3.6 shim execute 3.6.8 without needing to set up the .python-version files, you'd run pyenv global 3.6.8 -- you can run this multiple times for different python versions as well: pyenv global 3.6.8 3.5.6 ...
The reason that you're likely not having these resolve inside tox is tox clears the environment when executing, so the PYTHON_VERSION environment variable will not carry through. You can turn that off by setting passenv= in your tox.ini. For example:
[testenv]
passenv = PYTHON_VERSION

Yum "cannot import name Errors" - Red Hat 4.4 with Python 2.6 / 2.7

Any yum command I try to run, returns the following:
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
cannot import name Errors
Please install a package which provides this module, or
verify that the module is installed correctly.
It's possible that the above module doesn't match the
current version of Python, which is:
2.6.6 (r266:84292, Aug 18 2016, 15:13:37)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-17)]
If you cannot solve this problem yourself, please go to
the yum faq at:
http://yum.baseurl.org/wiki/Faq
This is what I've done and what I know:
OS is Red hat 4.4.7018
I believe Python was 2.6 and was updated to 2.7 some time ago (I suspect this might have broken yum)
python -V returns 2.7.13
# ls -lrt /usr/bin/python*
-rwxr-xr-x. 1 root root 4864 Aug 18 2016 /usr/bin/python2.6
lrwxrwxrwx. 1 root root 6 Mar 8 13:16 /usr/bin/python2 -> python
lrwxrwxrwx. 1 root root 24 Mar 8 13:32 /usr/bin/python -> /usr/local/bin/python2.7
# ls /usr/bin/python*
/usr/bin/python /usr/bin/python2 /usr/bin/python2.6
# ls /usr/local/bin/python*
/usr/local/bin/python2.7 /usr/local/bin/python2.7-config
I've tried running import yum on all phytons and only the 2.6 does not give me an error, so I tried changing the links back to 2.6 (Validated with python -V to check it goes back to version 2.6.6), and yum still returns the "cannot import name Errors" error.
Also, the PATH variable:
# echo $PATH
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:/usr/local/git/bin:/root/bin
The python configured on /usr/bin/yum is #!/usr/bin/python2.6, I've tried changing it to /python, and even /phyton2 and I still get the error.

the yum command in old version of red hat(6 and older) work with python 2.6
are you test yum command with unlink /usr/bin/python and add new link from /bin/python to /usr/bin/python2.6 ?
if the result is like same error try to recompile python6 OR update your yum pkgs on server

I'm not a Linux expert, but this looks like Red Hat 6 (which had python 2.6 as default) [1]. The 4.4 is the version of GCC. When you've got python 2.6 back in place and still need Python 2.7, then install the latter via the Software Collections channel - this will install 2.7 alongside the 2.6 version and not replace it to mess up the OS.
[1] How to confirm RedHat Enterprise Linux version?
[2]https://developers.redhat.com/products/softwarecollections/hello-world/#fndtn-python

pyenv 'system' version inconsistent with 'real' python version

In my ubuntu 16.04 system I have the following pyenv versions
$ pyenv versions
* system (set by /home/myuser/.pyenv/version)
3.6.0
3.6.0/envs/general
general
I intend that the version named system should coincide with the real system one, but when I check which python version will be executed, I get:
$ python --version
Python 3.6.0
$ which python # expecting /usr/bin/python
/home/myuser/.pyenv/shims/python
instead of the expected /usr/bin/python symlink which points to python2.7
$ ll /usr/bin/python
lrwxrwxrwx 1 root root 9 apr 18 10:11 /usr/bin/python -> python2.7*
Why is that? Is there something that I understand wrong?
How do I reset the pyenv system to make it coherent with the real system? I want to be sure of using the real system python when executing normal commands in my home dir.

Trouble creating a virtualenv for python3 on OS X

I'm having a strange problem with a virtualenv I've created for python 3. I went through the usual steps:
$ virtualenv --python=/opt/local/bin/python3.3 .py3
$ source .py3/bin/activate
The problem I'm having is that when I call python --version, it is still reporting 2.7.5, even though the paths all appear to be set up correctly. My virtualenv was created in /Users/barry.flinn/projects/.py3/bin, and I get thes results when I run which python:
$ which python
/Users/barry.flinn/projects/.py3/bin/python
The bin folder has the following python executables:
lrwxr-xr-x 1 barry.flinn obfuscated\Domain Users 9 Sep 23 19:39 python -> python3.3
lrwxr-xr-x 1 barry.flinn obfuscated\Domain Users 9 Sep 23 19:39 python3 -> python3.3
-rwxr-xr-x 1 barry.flinn obfuscated\Domain Users 9100 Sep 23 19:39 python3.3
Clearly, invoking python should give me python 3.3, and yet it still seems to revert to the system python, which is 2.7.5. My $PATH when the virtualenv is active is:
/Users/barry.flinn/projects/.py3/bin:/usr/local/mysql/bin:/opt/local/lib/postgresql92/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/go/bin:/usr/local/munki
Since all of this seems correct, I'm stumped as to what is going on here.
Update:
This reports correctly:
$ env python --version
Python 3.3.2
Which, to me, is slightly more baffling.

If you have a shell alias defined for the python interpreter, it will override the python chosen for your virtualenv. For example:
user#x790:~/temp$ alias python=/usr/bin/python
user#x790:~/temp$ python --version
Python 2.7.4
user#x790:~/temp$ virtualenv --python=/usr/bin/python3 foo
Running virtualenv with interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in foo/bin/python3
Also creating executable in foo/bin/python
Installing distribute.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................done.
Installing pip................done.
user#x790:~/temp$ . foo/bin/activate
(foo)user#x790:~/temp$ python --version
Python 2.7.4
Note that the python version reported was 2.7.4, even though python3 was selected for the virtualenv. Using the env command circumvents the alias:
(foo)user#x790:~/temp$ env python --version
Python 3.3.1
Lastly, you can get around this issue by either temporarily disabling the python alias for a single command or permanently undefining it:
(foo)user#x790:~/temp$ \python --version
Python 3.3.1
(foo)user#x790:~/temp$ unalias python
(foo)user#x790:~/temp$ python --version
Python 3.3.1