So, a couple of things. There is no IDE context with regards to python. When the IDE runs your script, it starts a new process where the python interpreter executes.(Updated Title)
This is the way things fit together:
Definitions:
1. "system context":
Anything run within a terminal window, (command line), called during boot, or anything executed outside an IDE.
2. "IDE context":
Anything run within an IDE like Thonny, mu, or anything else.
Background:
1. GoPiGo background robot libraries and software:
* Run continuously after the robot finishes booting.
* Manages its own SPI and i2c communication independently of any other processes that use it.
* Manages its own mutexes in /run/lock
* Runs in the "system context" as defined above.
* Fully respects the system path.
2. A terminal session as either "pi" or "root":
* Runs on demand.
* Manages things under program control.
* Runs within the "system context" as defined above.
* Fully respects the system path.
3. An IDE session, IDE started as either "pi", or "root" from the command line (sudo thonny, etc.)
* Runs on demand.
* Manages things both under program control and by itself.
* Runs within its own local context. ("IDE context" as defined above.)
* Completely ignores the system path unless it is specifically noted within the program file and local paths are appended.
Structure:
1. The GoPiGo libraries normally run from egg files in the normal system Python path as installed.
2. If I redirect the library paths in the system profile, (/etc/profile), it uses those.
3. The Waveshare e-Paper display demo code and libraries rum within %home%/e_paper.
* Though they can run from a command line, they are typically run within a context like Thonny so you can see the program's output.
Problem:
In order for my SPI mutex tests to be valid, (AFAIK), they must be using the same library include paths to be valid because I may run both GoPiGo AND Waveshare software at the same time in two IDE windows to whatch how they interact
I am not a sufficiently experienced programmer, nor am I an expert in the way GoPiGo libraries work, so I am compelled to assume they must run within the same path context, especially if I am running them side-by-side in an IDE where I can control them.
Also:
1. I want to isolate the GoPiGo libraries I am using to test from the system installed GoPiGo libraries.
2. I cannot assume that files and/or libraries called/included during program execution, (which can call/include other libraries outside my control), execute in the same path context as the original program.
Therefore:
I want to guarantee that any and all processes/programs run within the same path context. Ideally the system path as I defined it within /etc/profile.
I do not want to depend on explicitly specified paths in the code since I cannot guarantee that all parts of the code running within the IDE's context use the same path specification.
So if you open a terminal and do "export TEST=123", when you run your script from the IDE, the IDE runs python in a process that does not know TEST was even set.
The IDE always runs python in a new separate process, even if you start the IDE from the terminal where you previously set that variable.
But not this:
I bet this is your problem. When you run sudo, whatever sudo executes has no access to any environments. So like before, if you start a terminal, set a variable then sudo something, the something executes without knowing anything about the variable you set.3. An IDE session, IDE started as either "pi", or "root" from the command line (sudo thonny, etc.)
You can try
Code:
sudo -E mycmd "-E, --preserve-env
Indicates to the security policy that the user wishes to preserve their existing environment variables. The security policy may return an error if the user does not have permission to preserve the environment."
So you
Code:
export A=123Code:
sudo -E whateverFurthermore, there is the -i flag:
"-i, --login
Run the shell specified by the target user's password database entry as a login shell. This means that login-specific resource files such as .profile or .login will be read by the shell. If a command is specified, it is passed to the shell for execution via the shell's -c option. If no command is specified, an interactive shell is executed. sudo attempts to change to that user's home directory before running the shell. The command is run with an environment similar to the one a user would receive at log in. The Command Environment section in the sudoers(5) manual documents how the -i option affects the environment in which a command is run when the sudoers policy is in use."
The problem here is, that if you run sudo -E vscode or sudo -i vscode, it uses the variables and/or reads the users profile, etc. All is good, but now VSCODE executes python in a different process that has no idea of the process running VSCODE itself. This process has no idea your "IDE context" exists.
What you need to do is to set PYTHONPATH so that it is available for any process.
So you start VSCODE, open a new terminal in VSCODE, and in that terminal you set PYTHONPATH, and only then you manually run python myscrip.py from that same termainal. Now the script will see the updated values in PYTHONPATH. I don't know how you'd do it in thonny, but the same principle applies. Where it's doable or not, I don't know.
Or you can execute
Code:
export PYTHONPATH=$PYTHONPAT:foo/bar && python myscript.pyStatistics: Posted by memjr — Wed Jul 03, 2024 5:18 pm