In README file of omniORBpy-3.4 is written that I have to set PYTHONPATH as
set PYTHONPATH=%PYTHONPATH%;%TOP%\lib\python;%TOP%\lib\x86_win32
Where %TOP% is the top-level omniORBpy directory. (Windows machine)
I have done that and reboot my machine but when I try to run *.py files which have a line like
import omniORB
it gives me an error that no such module omniORB.
What I should do?
I think you will find that the README file of omniORBpy says that TOP must be set to the "the root of your omniORB tree" and not omniORBpy.
Not sure here, but I don't think, that changes made to the environment via a batch script will persist across reboots. Try setting the variable via the Workstation properties (sorry, I have no Windows machine at hand, and cannot give more than a few general directions):
Right click on the Workstation icon on your desktop.
Select "Manage..." (I think it was)
Somewhere in the advanced settings, you can modify environment variables (no need to reboot, but you may have to fire up a new CMD.EXE afterwards, as running apps might not get the change).
Alternatively, you can create a small batch script to start you application, and make it modify the environment before the application is started (I think, this is, what the README actually suggests)
Related
I have a folder mysrc in my project root and I'd like to make all tools of VScode work with import mysrc. The only way I found to make it work is to put the full absolute path PYTHONPATH=<fullpath_to_workfolder> in the .env file. But ideally I'd like to use relative paths to the workfolder.
How can I do that?
All suggestions I found (also here) somehow do not work. ${workspaceFolder} is empty. PYTHONPATH=. does not work. Ideally I'd configure a single PYTHONPATH and not for every tool (terminal, notebooks, mypy, ...). And even my solution for whatever reason duplicates PYTHONPATH=<fullpath_to_workfolder>;<fullpath_to_workfolder> on Windows when I inspect this variable in my code. I believe on Linux I did not have issues.
I'm not sure if this is what you want, but you could create a batch file with the following lines:
#echo off
set PYTHONPATH=%cd%
"%LOCALAPPDATA%\Programs\Microsoft VS Code\Code.exe"
(assuming default VS Code installation directory — you might have to change the last line if you installed it in another directory.)
This would call VS Code with the PYTHONPATH environment variable set to the directory from where you call it.
You can confirm this by opening a terminal window in VS Code and typing echo %PYTHONPATH%. All processes spawned from VS Code will inherit the environment variables, so this should work for all tools.
If you copy the batch script to another project and call it from there, all tools would then use that directory.
Sorry, but it works when I add these in the .env file:
PYTHONPATH=.\
or
PYTHONPATH=.
Could you reconfirm it?
Update:
.env file has no influence on the Jupyter NoteBook, but it works on linters, formatters, IntelliSense, and testing tools.
You can configure this to achieve it:
"jupyter.notebookFileRoot": "${workspaceFolder}",
I wasn't sure exactly how to ask my question in one concise sentence for the title so please give me the chance to be a bit more specific here.
So I've recently learned and have been told that working in virtual environments, or getting in the habit of doing so, is best for python (and I assume for many other applicable languages). Thus, I can create a virtual environment via virtualenv on the mac console and get it to activate and deactivate all that shenanigans in console. For example, when I work with this folder I have created a virtual environment for (via console) in vscode, it looks like this. I made sure that the python it was running seen on the bottom left of the screenshot included the virtual environment python noted by the "('learnpp')" symbol as I assume it's what I want. Now, my question(s) are:
do I have to go activate/deactivate the virtual environment on console before I start to work on anything despite having it set up like so (like in the screenshot) for the environment to actually work every time or does the IDE take care of it?
in the same screenshot, everything except the "draft.py" file was preloaded as a result of creating the virtual environment in seen folder which I strongly assume manages/runs the virtual environment so I was wondering if it was ok to "go about my day" creating files and folders despite all the mentioned things present. (I imagine I would just create a separate folder for the application I am creating to make life easier within the virtual environment folder OR would I be better off making an entirely new folder from the root folder?) In other words, instead of LEARN.PP/learnpp/"folder for my application" I would just create a new folder from LEARN.PP/ separately.
anything else useful I should know? (feel free to throw anything at me since I am a beginner)
Lastly, thanks for your time and I hope you have a great day!
For the virtual environment in VS Code, it is recommended that you separate its folders and scripts to avoid the impact of file interference, and separating them is easier to manage.
For example: 1. ".env" and ".env_3.9" are two virtual environment folders, which have their own dependencies and installed modules and so on; 2. ".vscode" is the folder where the configuration files are stored (settings.json; launch.json; tasks.json and so on.); 3. "a_De" is the folder where the python script is stored. and we can also store other types of files (executable files, read files and so on).
For more information about the use of python in VS Code, you can refer to: Editing Python in Visual Studio Code and Using Python environments in VS Code and Integrated Terminal.
I am trying to learn Python coming from R. I am used to the Project functionality provided by RStudio, that I can create a new Project and start a new session loading the file with '.Rproj'. The new session automatically uses the folder as the working directory and then I can set all the paths relatively. No need to change anything for different computers etc.
I tried asking people more familiar with python but usually nobody really understood my question. I heard, this would not be a problem once i started using jupyter or other stuff correctly when I were to use my files on another session.
My questions is then either if there is something like the Project functionality from RStudio or how do I better manage my projects across different computer. I could not any good links on that.
I am not so much familiar with R studio, but the functionality that you described are available on spyder IDE. You have dedicated project window and you and switch between project. There are many more functionalities (lie an always-on python console, variable/function display).
Please check
https://www.spyder-ide.org/
You can further use the python os package to make your code os independent.
I have the same issue. Though the main thing I use RStudio Projects for is to manage the working directory, and open RStudio in the right place. The best I've come up with is very specific to my problem - it doesn't do any of the other stuff .rproj and RStudio do, and isn't terribly portable.
I'm on Windows, using anaconda and JupyterLab in (it's not quite RStudio, but seems a good option to me) and I've found it a pain to navigate to the right location with the right environment for each project.
My understanding of python isn't great, but it looks like with jupyter lab .ipynb files the default working directory is the directory the file is in (so doesn't suffer from the chronic setwd() issue that .rproj helps to eliminate).
So I've created a .bat file (called pyproj.bat in this case) in the root of my project folder structure, to open jupyterlab in the right python environment:
call <anaconda_dir>/Scripts/activate.bat
call conda activate <project_environment_name>
call jupyter lab
cmd /k
My first line of that script is call %USERPROFILE%/Anaconda3/Scripts/activate.bat which at least gives it a chance of being portable between users in my organisation.
Would be nice if there were something a bit more automatic that could handle this - e.g. better searching for the activate script, and perhaps the environment management too (perhaps write the .yml and offer to build the environment if it's not present)
(Borrowed some the .bat idea from this question: How to make batch files run in anaconda prompt)
According to the docker-machine documentation for installation on Windows, I need to run the following command to add ssh.exe to the %PATH% environment variable:
set PATH=%PATH%;"c:\Program Files (x86)\Git\bin"
This is so that cmd.exe can recognize docker-machine as a command. However, running the above command just doesn't seem to do anything at all. The same thing happens when I try this in Powershell:
$Env:Path = "${Env:Path};c:\Program Files (x86)\Git\bin"
which is to say, apparently nothing at all. My goal is to make docker-machine a recognizable command in cmd.exe. This is because I have a Python script to set up the docker-machine VM and the script needs to be able to run in cmd.exe. How exactly can this be done? It's important to not go into Advanced System Settings from My Computer and modify environment variables that way, since that requires admin privileges and the setup needs to work without any sort of admin privileges.
It's important to not go into Advanced System Settings from My
Computer and modify environment variables that way, since that
requires admin privileges and the setup needs to work without any sort
of admin privileges.
A non-admin user can set environment variables that only affect their profile (as opposed to the entire machine). See this answer for how to access the Environment Variables dialog directly without having to go through the Advanced System Settings dialog.
From here, you can set PATH in the User variables list. Note that, when using this method, you don't need to include the existing path (i.e. %PATH%) as you did above. The value you enter in the User variables list will be appended to the current system value for PATH.
Also, don't forget that after setting an environment variable using this method, existing cmd instances will not see the new value for PATH -- you must open a new cmd instance.
Perhaps the original set command is necessary, but it is definitely not the whole story. I found out after a lot of digging around that you need to make sure that Docker Toolbox is also in your PATH variable. The following needs to be added:
C:\Program Files\Docker Toolbox
I don't know why the Docker documentation neglects to mention this. Maybe it's assumed that it will automatically make it there after installation. In my case, that is not what happened and I had to manually ensure that Docker Toolbox was in PATH.
Thanks to Rusty Shackleford for helping me find the environment variables without using admin privileges.
Sometimes when I change my environment variables in Windows, and then use software the depends on those variables, they are not properly updated.
And good example is to change a variable, then open up Windows Command Line and echo the variable and see that it hasn't been changed, even though you properly changed it in the Environment Variables window.
Another example I'm dealing with right now:
I've been using Python 2.4.x for a while for a project, which uses the env var PYTHONPATH who's value has been:
C:\Python24;C:\Python24\lib
Today I installed Python 2.5.x for the project. I changed my PYTHONPATH to be:
C:\Python25;C:\Python25\lib
When I use Python 2.5 to run a script and do this:
import sys
print sys.path
It prints:
'C:\\PYTHON24', 'C:\\PYTHON24\\lib' (and some other Python 2.5 related default installation paths)
So clearly, the old PYTHONPATH environment variable changes aren't really sticking....
Does anyone know why this happens and how to fix it?
When you change an environment variable in the System Properties tab, the new value will propagate to the Windows Explorer, and any apps (such as cmd.exe) opened from the Windows Explorer (or the Run box, Start Menu, etc.) should see the new value.
However, if you're running a program such as an editor or python or some non-Microsoft program launcher, then change an environment variable, and then launch cmd.exe from that program (instead of Windows Explorer) you are likely to see the old value of the environment variable. The reason is that the running program ignored the notification from Windows saying that the environment has changed (not at all unusual), and since the launched process inherits the environment variables, the child process won't see the changes.
The workaround is to make sure you start your app from Windows Explorer or the Run box. Rebooting your machine will work also (if rebooting doesn't solve the problem, then something else is going on).