If I run pytest inside of Emacs, using M-X compile, $TERM gets set to "dumb", and this seems to confuse pytest's attempt to draw a line of =s across the full width of the screen. It gets the width one too high, resulting in hard to read output with extra folded lines.
Running unset COLUMNS; pytest helps a little, but it's still trying to do some fancy overwriting by issuing raw carriage-returns, and messing that up. I've also tried setting various values for $TERM (ansi, glass-tty, etc). I even tried, unset TERM.
Any way to convince pytest to just produce dumb output and not try to do any fancy output formatting?
I'm also open to ideas on how to pistol-whip emacs into setting the environment correctly :-)
I'm running:
GNU Emacs 22.1.1
Python 3.6.2
pytest version 3.4.0
MacOS 10.12.6 (16G1212)
Terminal Version 2.7.3 (388.1.1)
Try pytest.el, or at least check how it invokes py.test. I use it with Spacemacs (it's included in the Python layer), and have never seen any issues with its terminal handling.
Related
I recently found a fix for Python getpass not working on Windows: Python not working in the command line of git bash
Or at least that was the last thing I remember about changing my python configurations. (This is for Python 3.6.1 on Windows 10)
Now I also use Python to other tasks which simply has subprocess calls to type several commands on terminal:
go build ./folder/
mv ./src/ ./bin/
I get the error: go: GOPATH entry is relative; must be absolute: "/c/Users/OP/work". But I don't get it if I type go build ./src/folder myself.
I have GOPATH set to C:\work in Environment Variables. I have tried with a ;.
Is there a way to reverse the alias python every time? Or what is happening exactly when setting an alias for python to winpty?
I'm thinking that when I call go build directly, it is called by either my user profile or system. And when python's subprocess calls it, it calls the opposite. Therefore, I have two GOPATH variables even though I have only 1 set in environment variable.
Side Note: another recent change on GOPATH was changing it from C:/go because it couldn't be the same as GOROOT. That error popped up randomly for some reason. It worked with that setting for a while and I don't remember changing anything before except adding another import package on top of the many other ones already being used.
Update: with type python I get the result: python is aliased to 'winpty python.exe'. Therefore I tried to undo that with unalias python. The new result I get is: python is hashed (/c/Users/OP/AppData/Local/Programs/Python/Python36/python).
This fixed the go build command within Python's subprocess. However, that alias was a fix for another Python issue with using getpass package.
On top of my unalias python fix, I also discovered something interesting: when I change the environment variables for GOPATH from C:\work; to C:\go, all go commands still spit the error go: GOPATH entry is relative; must be absolute: "". I got this same error (but different path) from updating Windows 10 Fall Creators update. Maybe it is related.
Simply closing MINGW and reopening it fixed the issue. So perhaps it was saying a copy of my environment variables and using that as a reference instead of the actual system properties.
I know this is not a popular question, but someone could benefit from my hours of investigating and debugging.
Under Windows you must use a Windows style GOPATH like eg d:\code and probably you should use cmd shell and nothing else. Unfortunately cygwin paths (and probably others too) do no longer work especially for go get reaching out to git.
Stick to Windows paths and Windows shell.
I am quite new with configuring Jenkins or Python but I have to set up a unitary test in Jenkins. My program is in Python, but only works on Python 2.6 whereas the Jenkins version I should be using is 2.7, so I'm trying to set up Jenkins to set some environment variables so that it prepares launching the accurate Python for that specific test (it is part of a greater project that will successfully run several other tests that work well).
The idea I had was to set in the command to execute several environment variables like PATH, LD_LIBRARY_PATH and PYTHONPATH such as following in the "Execute shell" command line interpreter:
PYTHONPATH=/path/to/python2.6/lib:$PYTHONPATH
PATH=/path/to/python2.6/bin:$PATH
LD_LIBRARY_PATH=/path/to/python2.6/lib:$LD_LIBRARY_PATH
... however, it was still calling the wrong version of Python. Therefore, I forced these variables to:
PYTHONPATH=/path/to/python2.6/lib
PATH=/path/to/python2.6/bin
LD_LIBRARY_PATH=/path/to/python2.6/lib
... and I still get errors because the old version of Python is called instead, even if it should not appear in the PATH ... It appears Jenkins will remember the location of the old libraries however and will try loading them first.
How would I correctly set the environment in a "subproject" in Jenkins so that I can call a different version of Python?
Thank you and best regards,
~Stéphane
If you want your program to run with a specific version of the python interpreter, you indicate it in the shebang
#!/usr/bin/python2.6
#your code here
What i did in my Jenkins shell script using a specific python version was something like this when calling my unit test:
python3 src/test/unit_test.py
I was using it to use Python 3.X but it should work with 2.6 as well using:
python2.6 src/test/unit_test.py
Stupid me... I was indeed doing things correctly, I just had a part of my code that was overriding the PYTHONPATH value, so the solution I had found previously was good.
FYI, I modified my shebang, if it's of any help to anyone ;)
I changed two days ago to Emacs 23, which lately gave me a lot of headache, especially, as I have two Python versions installed, the older 2.7 and 3. As I generally want to start the python 3 interpreter, it would be nice if I could tell Emacs in some way to use python 3 instead of 2.7.
Besides, I could not find a module which helps to highlight python3 syntax. I am currently using python-mode.el for highlighting.
Also, if somebody had a good tip for which module would be best to show the pydoc, I would be very thankful.
Thanks in advance!
If you're using python-mode.el, you can specify the binary to be executed as an inferior process by setting the py-python-command variable, i.e.:
(setq py-python-command "python3")
Naturally, you'll need to provide the name of the binary as it exists on your system in place of "python3", if it differs. In python.el, the analogous variable to set is python-python-command.
As far as using pydoc, there are a few possibilities. First, you can simply execute help() inside the Python inferior process. If you do choose that option, you might find it useful to add the following code to your .emacs file:
(setenv "PAGER" "cat")
This is necessary because interactive pagers (e.g., less, more, most, etc.) don't work particularly well inside inferior process buffers. Second, you can install a Texinfo package containing the documentation and use Emacs's info browser (q.v., Python Programming in Emacs). Finally, if you opt to use python.el, it includes an interactive function called python-describe-symbol that can lookup pydoc help on demand (and I suspect python-mode.el should have something similar). If you search around a bit, I'm sure you can find other methods and/or third-party packages as well.
[RET] = enter or return key.
M = Meta or Alt key.
If you feel like letting Emacs do the heavy lifting for you, go through the Emacs settings dialogue to have Emacs set it automatically.
M-x customize-variable [RET] python-shell-interpreter [RET]
A new buffer should appear where you can customize the python interpreter you are using.
The field to the right of Python Shell Interpreter: will be the current interpreter your are using. In my case it was python so I changed it to python3. Then move the curer to select the Apply and Save button above and hit [RET] to make Emacs respect the new setting. Alternatively you can click the button with the mouse.
Next time you open the Emacs python interpreter, it will be using the new python you set from the setting dialogue.
After I did the following thing, I got the behavior that: when editing a Python file in emacs, C-c C-p creates a new buffer with a Python3 interpreter.
Add to your .emacs file the following:
(defcustom python-shell-interpreter "python3"
"Default Python interpreter for shell."
:type 'string
:group 'python)
The reason I tried this, was because I found
(defcustom python-shell-interpreter "python"
"Default Python interpreter for shell."
:type 'string
:group 'python)
in python.el. And I hypothesized (i) that the "python" could be substituted with "python3" and (ii) that this would override the definition in python.el.
It is likely that there are reasons why this is inelegant or heavy-handed or otherwise bad. I am an emacs newb.
start an python-interpreter
M-x python RET
(the default interpreter)
M-x pythonVERSION
where VERSION means any installed version
Inspired by #serv-inc's answer you can also put
(setq python-shell-interpreter "python3")
into your ./.emacs.d/init.el or where you store your configuration.
It's December 2020, I'm using EMACS 25, otherwise unconfigured for python, and I found that:
(setq python-shell-interpreter "python3")
added to my .emacs file did the business and led to a reasonably intuitive way of working with python3. C-c C-c sends my file to the interpreter (or asks me to start a new interpreter, and tells me how).
Of course, now the python3 interpreter runs for any python file, so python 2 programs don't work.
I am imagining a better world where emacs looks at the #!/usr/bin/env python2 line at the top of my file and figures out which interpreter to start by some kind of insane high-tech magic.
Note python-mode.el knows a hierarchy how to detect the version needed
a shebang precedes setting of py-shell-name
while py-execute-THING-PYTHONVERSION
would precede also shebang for the command being
see menu PyExec
I have GNU Emacs 23 (package emacs23) installed on an Ubuntu 10.04 desktop machine and package emacs23-nox installed on an Ubuntu 10.04 headless server (no X installed). Both installations have the same ~/.emacs file. I run Emacs with -nw on both computers. I don't have python-mode installed on either machine as my understanding is that this is included in Emacs 23.
On the desktop machine, comments in Python (starting with #) are highlighted in red. On the server, comments appear in plain white text like all other non-highlighted text. Any suggestions as to why comments are not being highlighted correctly on the server (nox) installation?
Update: This appears to be a terminal-related issue. I ssh into the server machine from terminator via the screen replacement byobu. If I run emacs on the server with TERM="xterm-256color" emacs, then comments are highlighted, but all the other colours look very strange.
Update: Adding `export TERM="xterm-256color" "solved" this. The syntax highlighting now has very strange colours though: purples lilacs and light browns. My green current line highlight bar is now a light pale yellow/green. Comments are highlighted in red though :)
Update: Solved. Setting TERM="xterm-color" produces "proper" colors, including highlighting of comments. The server was defaulting to a value of "screen-bce" for TERM which was not highlighting comments.
Update: Unsolved. byobu provides keybindings for various function keys to easily create new screen sessions and switch between them. When TERM is set to xterm-color, these function keys no longer work. So I guess I'll just have to be happy with unhighlighted comments in Python code in Emacs.
For me running emacs -nw from inside byobu with TERM=xterm produced the correct colours for syntax highlighting (the comments in python and bash are all red not just the #) and the function keys work. Note I set TERM as part of an alias for running emacs rather than setting it generally in .bashrc:
alias emacs='TERM=xterm; emacs -nw'
See also this post: Terminal emacs colors only work with TERM=xterm-256color
I don't have the programs you are using installed to test this, but I did notice some differences in the way the function keys are defined between screen-bce and xterm-color. You can try using the below steps to copy the settings from screen-bce to xterm-color.
Using the infocmp program, you can view the differences between the terminfo settings for two TERM settings:
infocmp -d screen-bce xterm-color
You can use infocmp to decompile the terminfo file to its source and make changes to it to try to mimic the behavior of the other terminal. Start by decoding the xterm-color terminfo file.
infocmp xterm-color > xterm-color.src
Edit xterm-color.src and modify the definitions of the kf1 through kf19 fields to match the values for screen-bce. Use infocmp to see screen-bce's definitions.
infocmp screen-bce
Finally compile using the tic program.
tic xterm-color.src
If you run it as a non-root user, it will put the compiled terminfo file into $HOME/.terminfo directory. On my system, it seems like Ubuntu picks this up automatically. You can also install it into the standard /usr/share/terminfo when you're satisfied. Running tic as root should do this for you.
Good luck!
I just added
(set-face-foreground 'font-lock-comment-face "red")
to my .emacs
I'm developing a django app using aquamacs as my ide. Pdb isn't working since upgrading to emacs 23.2.1 using python 2.6.1. When I invoke pdb like this:
M-x pdb
Run pdb (like this): pdb ./manage.py runserver
The gud-manage.py frame appears with this message (and nothing more) -
Current directory is /path/to/my/source/
It isn't responsive to keyboard input, though I can right-click and send a quit or kill signal. It seems like emacs isn't capturing the pdb output correctly.
Has anyone seen this and (hopefully) fixed it? I believe it has something to do with the gud-pdb-marker-regexp variable (see point #2 in link).
Related issues
Seems to have been around since 2007
One person a solution for this problem on Windows (adding -u to the python command in the pdb script). I tried it anyway, but this didn't work for me.
Same issue (Current directory is ...) to me with emacs 23.2 (9). As you mentioned, it is caused by a CR/LF ending and can be fixed by setting the gud-pdb-marker-regexp.
I added the CR (\r) to the gud-pdb-marker-regexp. May you want to add the following line to your .emacs file and give it a try.
(setq gud-pdb-marker-regexp "^> \\([-axx-zA-Z0-9_/.:\\]*\\|<string>\\)(\\([0-9]+\\))\\([a-zA-Z0-9_]*\\|\\?\\|<module>\\)()\\(->[^\n\r]*\\)?[\n\r]")
Not sure if that is the case for you, but just to mention it: PDB hangs for me in Emacs when the source code path contains a space - when I move the python file to a directory without a space in the name, it works (on Emacs 23.1.1).
I have been having this same issue. I had it fixed in 23.1 (http://debbugs.gnu.org/db/56/5653.html) but now in 23.2 that fix no longer works, or at least it doesn't appear to for me. I've just submitted a bug to Emacs explaining the problem in detail and hopefully it will get resolved.
A workaround for this is to execute pdb from the emacs shell:
Open the shell: M-x shell
Enter this in the shell: pdb
This will get pdb working properly within the shell.