I'm calling another program with a piece of code that looks like this:
import subprocess
lc="/package/bin/program --do stuff"
command_list = lc.split()
ljs=subprocess.Popen(command_list,stdout=subprocess.PIPE)
ljs.communicate()[0]
The string works fine at the UNIX command line and the code works in Python 2.7. But, in Python 3.4, I get an error like this:
File "/package/bin/program", line 2, in <module>
from package import module
ImportError: No module named package
"/package/bin/program" is calling a dependency from another file in the package here, which I think is the core issue. I have calls to other programs that are working fine in 3.4.
What's changed in 3.4 that might be causing this?
(Sorry in advance for the cryptic code - I'm calling company internal tools that I can't expose here).
The problem is that the working directory of the subproccess instance is default the directory of bash shell. To set a new working directory, set the cwd argument in your Popen to your working directory.
Here's an example:
subprocess.Popen(['random' '--command'], stdout = subprocess.PIPE, cwd='C:/Path/To/Working/Directory/')
Comments above have been helpful in exploring the issue, but at the end of the day this seems to be some permissions conflict - adding a sudo -u <user> before the command fixes the issue. Still not clear why Py3 requires this and Py2 doesn't, but perhaps I need to explore the issue more closely with other internal users.
Thanks!
Related
I have a CodeDeploy which deploys application on Windows instances. I have a Python script which is running as part of ValidateService hooks. Below is the code I have in that script:
print("hello")
So, I have removed everything and just printing hello as part of this script. When this script is called by CodeDeploy I get below error:
My appspec.yml file:
...
ValidateService:
- location: scripts/verify_deployment.py
timeout: 900
I tried getting some help on Google but got nothing. Can someone please help me here.
Thanks
As Marcin already answered in a comment, I don't think you can simply run python scripts in CodeDeploy. At least not natively.
The error you see means that Windows does not know how to execute the script you have provided. AFAIK Windows can't run python natively (like most linux distros can).
I am not very accustomed to CodeDeploy, but given the example at https://github.com/aws-samples/aws-codedeploy-samples/tree/master/applications/SampleApp_Windows, I think you have to install python first.
After so much of investigations, I found my answer. The issue is little misleading, there is nothing to do with Code format or ENOEXEC. The issue was due to Python path. While executing my script, CodeDeploy was unable to find Python (Though I had already added python.exe in Environment variable path).
Also, I found that CodeDeploy is unable to execute .py file due to Python path issue. So, I created a PowerShell script and invoking Python script from there. Like below:
C:\Users\<username>\AppData\Local\Programs\Python\Python37-32\python.exe C:\Users\<username>\Documents\verify_deployment.py
It executed Python script successfully and gave me below output:
hello
I am trying to set up a cron job which is executing a python file of mine. The python file is using some manually installed modules. The cron job now throws an error, as it 'cannot find' the specified module (yes, I tested it: if executed manually the script does work & have access to the module).
I did now recieve the cryptic info (from the hoster’s support) to 'try adding the -m flag to the command, followed by the path to the module that it cannot find.' Unfortunatelly I do not quite understand this advice.
Assuming that my cron job command (via Cpanel) would out of the box be:
0 * * * * python /home/public_html/cgi-bin/cronrun.py
which works if the python script does not rely on external modules.
So my questions are:
Is the -m flag appropriate?
If so, how do I use it?
And what do I do, if there is more than just one additional module that the script needs?
Thank you very much in advance!
Your cron job won't likely be running with the same environment that you have. To see this, first run env > [somepath_that_you_can_reach]. Then set up a cron to do the same thing in a shell script using a different path. Compare the two. You will need your PYTHONPATH to be the same for the cron job to work. If that is the problem, then in your python script:
import sys
sys.path.append('[the path part that you need for it to work]')
before your import statements.
When I import the wx module in a python interpreter it works as expect. However, when I run a script (ie. test.py) with wx in the imports list, I need to write "python test.py" in order to run the script. If I try to execute "test.py" I get an import error saying there is no module named "wx". Why do I need to include the word python in my command?
PS the most helpful answer I found was "The Python used for the REPL is not the same as the Python the script is being run in. Print sys.executable to verify." but I don't understand what that means.
Write a two line script (named showexe.py for example):
import sys
print sys.executable
Run it both ways as showexe.py and python showexe.py. It will tell you if you're using the same executable in both cases. If not, then it'll depend on your operating system what you have to do to make the two run the same thing.
If you start your script with something like #!/usr/local/bin/python (but using the path to your python interpreter) you can run it without including python in your command, like a bash script.
I'm trying to run a python script from a python program by kicking it off from subprocess (The reason is that the main program has to have exited when the script runs, with a combination of wx.CallAfter and Close). However when the script runs I get an error on line 1 with ImportError: No module named os which makes me think it's something to do with the PythonPath, but I can run the script just fine from a terminal.
Why can't the script see any core modules when run this way?
Edit:
The line in question is:
wx.CallAfter(subprocess.Popen,'python %s "%s" %s %s'%(os.path.join(BASE_DIR,"updatecopy.py"),BASE_DIR,pos[0],pos[1]),shell=True)
BASE_DIR is just the directory that the script lives in.
subprocess is there because os.exec* has been deprecated so I wouldn't suggest using that in place of Popen as someone suggested.
I've seen this issue crop up when running from a frozen process. If that is the case then you're most likely inheriting a weird environment for the new python process.
Most frozen scripts will be trying to run from a zip file, in which case it's no wonder that Python can't find anything, it's all trapped in a zip file :)
If this is the situation then try running using the python executable that you are using to run the frozen script. It should be able to deal with the special environment.
Maybe you could use os.execv instead of Popen.
From os/python docs:
These functions all execute a new program, replacing the current process; they do not return. On Unix, the new executable is loaded into the current process, and will have the same process id as the caller. Errors will be reported as OSError exceptions.
(emphasis mine)
The story began with a very strange error while I was running my script from PyDev. Running the same script from outside will not encounter the same problem.
Fatal Python error: Py_Initialize: can't initialize sys standard streams
File "C:\Python26\lib\encodings\__init__.py", line 123
raise CodecRegistryError,\
^
SyntaxError: invalid syntax
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
I was able to find why this is happening: In PyDev I use two different Python versions: 3.1 that is the default installation and 2.6 as the alternative one.
My Windows Environment does not contains PYTHONHOME, CLASSPATH, PYTHONPATH but PyDev does add them.
Now the problem is at one stage my python script does execute another python script using os.system(python second.py) and the second script will fail with the above error.
Now I'm looking to find a way to prevent this issue, issue that is happening because it will run the execute the default python using the settings for the non-default one (added by PyDev).
I do not want to change the standard call (python file.py) but I want to be able to run my script from pydev without problem and being able to use default or alternative python environment.
Any ideas?
I found a solution that seams acceptable specially because it will not interfere with running the scripts on other systems, just to run python -E second.py - this will force Python to ignore PYTHON* environment variables.
I may not be understanding this quite right, but I think you're invoking a script from pydev that works okay, but this script executes another script which requires a different version.
While this would unfortunately be installation-specific, you could use os.system("c:\absolute\path\to\proper\version\of\python.exe second.py").
If PyDev is setting up conflicting environmental variables, you may want to look into subprocess over os.system.
http://docs.python.org/library/subprocess.html#using-the-subprocess-module
This will allow you to invoke a process with a handle, so you can optionally wait for it to terminate. It will also allow you to pass environment variables upon execution.
I believe your call should be:
import sys
os.system(sys.executable+ ' second.py')
So that you guarantee you're using the same interpreter you're currently running and not launching the other one (or did you really mean to use the other interpreter?)