I can run python files in cmd promt and Vscode terminal (cmd prompt). When I try to run any programme with Code runner ("code-runner.runInTerminal": false), I get the following error:
[Running] python "c:\Users\MY PATH INCLUDING WHITESPACE\hello_world.py"
Python was not found but can be installed from the Microsoft Store: https://go.microsoft.com/fwlink?linkID=2082640
Here are the user settings (settings.json) I have tried:
"code-runner.executorMap": {
"python": "python",
},
"code-runner.executorMap": {
"python": "$pythonPath $fullFileName",
},
"code-runner.executorMap": {
"python": "$pythonPath -u $fullFileName",
},
..but I always get the same error.
It seems like the problem could be related to code runner, but could have something to do with the setup of python on my machine.
It could potentially have something to do with the fact I have two python files for the location of python.exe:
(base) C:\>where python
C:\Users\<user_name>\AppData\Local\Continuum\anaconda3\python.exe
C:\Users\<user_name>\AppData\Local\Microsoft\WindowsApps\python.exe
This is the only difference I can think of to another machine where this actually works, but can't be sure.
Any ideas what the issue could be?
maybe try the following:
Change the executormap to:
"code-runner.executorMap": {
"python": "\"$pythonPath\" $fullFileName",
}
Also you could try to give a concrete python path, maybe create a venv and try there:
"python.pythonPath": "venv/bin/python"
If your directory tree has spaces - do this:
"code-runner.executorMap": {
"python": "\"$pythonPath\" -u $fullFileName",
}
This is in the case were the "python.pythonPath": "C:\Users\Documents and Settings\appdata\python\code\something something\script.py"
Spaces in the directory structure will abort the script and you'll get a response something like:
"C:\Users\Documents is not a valid directory."
So you need the escape character like someone above explained.
Related
we are using cobol now, but this config error keeps on appearing and I do not know how to fix this thing. Any help would really mean alot. (Just a beginner and trying to learn vscode)
Late, but perhaps worth it. Currently there is a cobenv.bat or .sh (if you are on linux). The whole path to the file may differ for me is this:
C:\msys64\mingw64\bin\cobenv.cmd
You'll notice that if you execute the file and run the compiler everything works fine, but once you close that bash the error shows up again.
That's because the scope of those variables was just that session. You may execute it every time you run the compiler or you can make those variables to persist on your system. In my case I did the later, modifying cobenv.cmd
But not those lines with the variable PATH.
So this lines, i.e., whenever we encounter this same three variables. For instance, after a certain if in that file we encounter:
setx "COB_LIBRARY_PATH" "%MINGW_ROOT_PATH%lib\gnucobol%COB_LIBRARY_PATH%"
setx "COB_COPY_DIR" "%MINGW_ROOT_PATH%share\gnucobol\copy"
setx "COB_CONFIG_DIR" "%MINGW_ROOT_PATH%share\gnucobol\config"
Default value: set.
New value: setx.
Delete the = to comply with the correct syntax. Check the compiler with different new session.
This message is only presented in vscode's Terminal after you've entered a command there, it is actually not related to vscode.
The "common" way with vscode would be to create a vscode task for the compilation and configure a problem matcher, too, so vscode is able to parse the messages. For details see vscode docs "Integrate with External Tools via Tasks".
As the message is coming from the GnuCOBOL compiler it may be reasonable to check in its discussion board, which also includes a note how to use your setup of vscode with GnuCOBOL MinGW package, this would be your starting point, assuming D:\COBOL is the place where you have your sources (and this is the alos the workspaceFolder as in your screenshot), D:\COBOL\copy where your copybook reside and D:\GnuCOBOL where the MinGW package is:
{
"version": "2.0.0",
"tasks": [
{
"label": "GnuCOBOL - cobc (compile single file)",
"type": "shell",
"command": "cobc",
"args": [
"-I${workspaceFolder}\\copy",
"${file}"
],
"problemMatcher": "$gnucobol3-cobc",
"options": {
"env": {
"COB_CFLAGS": "-I\"D:\\GnuCOBOL\\include\"",
"COB_CONFIG_DIR": "D:\\GnuCOBOL\\config",
"COB_COPY_DIR": "D:\\GnuCOBOL\\copy",
"COB_LDFLAGS": "-L\"D:\\GnuCOBOL\\lib\"",
"COB_LIBRARY_PATH": "D:\\GnuCOBOL\\extras",
"PATH": "D:\\GnuCOBOL\\bin:${env:PATH}"
}
},
"group": {
"kind": "build",
"isDefault": true
}
}
]
}
Instead of directly calling cobc you could also call cobc.bat or similar, then create it with all your default options set there (or, if you use the official mingw packages, just call the set_env.cmd) then call the compiler.
Concerning "how to fix that message" - make sure you have the "config" directory of GnuCOBOL and have COB_CONFIG_DIR set to it either in the task definition or outside of vscode (for example by starting vscode from the "Developer prompt for GnuCOBOL MinGW" (which is the set_env.cmd distributed with it).
I am trying to debug pytest. I would like to inject an environment variable. Here is how I have set launch.json
{
"type": "python",
"request": "test",
"name": "pytest",
"console": "integratedTerminal",
"env": {
"ENV_VAR":"RandomStuff"
}
},
But it seems when I start debugging. I do not see the env variable injected, as a result my test which expects that env variable fails.
Also I notice error
Could not load unit test config from launch.json
pytest-env
Install
Per https://stackoverflow.com/a/39162893/13697228:
conda install -c conda-forge pytest-env
Or:
pip install pytest-env
pytest.ini
Create pytest.ini file in project directory:
[pytest]
env =
ENV_VAR=RandomStuff
Python
In your code, load environment variables as you normally would:
import os
env_var = os.environ["ENV_VAR"]
pytest / VS Code
Either run:
pytest
(Notice how it says configfile: pytest.ini)
C:\Users\sterg\Documents\GitHub\sparks-baird\mp-time-split> pytest
==================================== test session starts ===================================== platform win32 -- Python 3.9.12, pytest-7.1.1, pluggy-1.0.0 rootdir:
C:\Users\sterg\Documents\GitHub\sparks-baird\mp-time-split,
configfile: pytest.ini plugins: anyio-3.6.1, cov-3.0.0, env-0.6.2
collecting ...
Or:
This only seems to work with breakpoints that have manually been set, I'm guessing some other change is needed to pause on errors.
Python for VS Code Extension
Apparently the Python for VS Code extension recognizes a .env file automatically. E.g.
.env file:
ENV_VAR=RandomStuff
Haven't verified, but I'd assume this has the same behavior as using pytest-env with a pytest.ini file.
When all else fails
When I don't feel like dealing with the strange hackery necessary to get VS Code, Anaconda environments, and pytest playing nicely together (and/or forget how I fixed it before), I call my tests manually and run it like a normal script (see below). This may not work with more advanced pytest trickery using fixtures for example. At the end of your Python script, you can add something like:
if __name__ == "__main__":
my_first_test()
my_second_test()
and run it in debug mode (F5) as normal.
Could not really figure out how to fix "unit" test debugging with Vscode. But with Pytest one can call tests like python -m pytest <test file>(https://docs.pytest.org/en/stable/usage.html#cmdline)
That means Vscode can be configured like a module
"configurations": [
{
"name": "Python: Module",
"type": "python",
"request": "launch",
"module": "pytest",
"args": ["--headful","--capture=no", "--html=report.html"],
}
This is good enough to do debugging of python tests. Also you can then insert environment variables
"env": {
"ENV_VAR":"RandomStuff"
}
This works in v 1.72.2
Create in the workspace folder:
.vscode/launch.json
Similar to the OP, but using "module"
{
"version": "0.2.0",
"configurations": [
{
"name": "Pytest",
"type": "python",
"request": "launch",
"module": "pytest",
"console": "integratedTerminal",
"env": {
"testy": "someval"
}
}
]
}
Try some breakpoints (either in test files or app code)
Start the debugger
Watch the os.environ['testy'] value (must import os where the breakpoint is of course)
In my devcontainer.json for vscode, I am trying to load in a build variable. This variable is on my local machine's environment, my code looks like the following:
//build arguments
"build": {
"args": {
"TOKEN": "${localEnv:TOKEN}"
}
}
It seems like it works when I put in a direct string, or something like "${localEnv:HOME}", but it is not picking up this custom one. which is strange because I can do 'printenv TOKEN' and it prints out correctly.
any ideas on what I may be doing wrong?
Add your export BLA=1 to .profile, this was the only way VScode was able to pass through env variables to the devcontainer.
.devcontainer:
{
"name": "devcontainer",
"build": {
"dockerfile": "${localWorkspaceFolder}/Dockerfile",
"context": "${localWorkspaceFolder}",
},
"remoteEnv": {
"FOO": "${localEnv:FOO}",
"BAR": "${localEnv:BAR}",
}
}
First, ensure that you have the VS Code Terminal -> Integrated: Inherit Env setting set to true. This is described on the Advanced Container Configuration page:
Workarounds
If that doesn't fix your problem (it didn't for me), here are some of the workarounds that I have found:
Set the variables in your ~/.bashrc file (or export them temporarily in the terminal) and start VS Code from a bash prompt (the executable is code).
$ export TOKEN=tokenvalue
$ code
Set the variables in your ~/.pam_environment file (these are available session wide and are inherited by applications started with the launcher). You will need to logout and login or reboot for these to apply.
TOKEN=tokenvalue
Set the environment variables in one of your VS Code settings files (user or workspace) using the Terminal -> Integrated Env: Linux setting:
// Object with environment variables that will be added to the VS Code process to be used by the terminal on Linux. Set to `null` to delete the environment variable.
"terminal.integrated.env.linux": {
"TOKEN": "tokenvalue"
},
Hi I will be using watchman to upload images. The images will have folders so I will be using .json to make the command.
These are my images:
/home/user/Documents/Images/folder1/image1.png
/home/user/Documents/Images/folder2/image2.png
I have a list of export environment variables watchman_env
export CONDA_ENV=image_uploader
export IMG_FOLDER=/home/user/Documents/Images
export UPLOADER_SCRIPT=/home/user/Documents/Script/uploader.sh
export PYTHON_UPLOADER=/home/user/Documents/Script/img_uploader.py
export JSON_TRIGGER=/home/user/Documents/Script/uploader.json
This is my uploader script, ~/Script/uploader.sh
. watchman_env
conda run -n $CONDA_ENV python $PYTHON_UPLOADER $IMG_FOLDER
This is my json configuration, ~/Script/uploader.json:
["trigger", "/home/user/Documents/Images", {
"name": "img_uploader",
"expression": ["match", "**/*.png"],
"command": ["/home/user/Documents/Script/uploader.sh"]
}]
I run the command using another bash file, init.sh, since I want to run some few more commands.
. watchman_env
watchman --json-command < $JSON_TRIGGER
When I run uploader.sh my python script uploads the two images. However, when I run init.sh, it does not trigger. What is wrong with my code? And is that correctly how to use json trigger?
wathman version: 4.9.0
I just added to the expression wholename and finally worked.
["trigger", "/home/user/Documents/Images", {
"name": "img_uploader",
"expression": ["match", "**/*.png", "wholename"],
"command": ["/home/user/Documents/Script/uploader.sh"]
}]
The following command works as expected:
protractor --cucumberOpts.tags='not #tag1' conf.js
Now I want to add this command as a script to package.json like this:
"scripts": {
"my-script": "protractor --cucumberOpts.tags='not #tag1' conf.js"
}
Running the command npm run my-script gives me the following error:
Usage: protractor [configFile] [options]
configFile defaults to protractor.conf.js
The [options] object will override values from the config file.
See the reference config for a full list of options.
Options:
...
Error: Error: more than one config file specified
Why is that?
Both of the commands seem to be identical.
This is not actually a protractor issue. I was able to recreate this issue and resolved it by using escaped doubles quotes in that script string like so.
"scripts": {
"my-script": "protractor --cucumberOpts.tags=\"not #tag1\" conf.js"
}
This issue (apparently) is to do with how node handles single quotes on different operating systems. There is some more info in this question.