I have been using Jenkins for a few years and recently bought a new Windows 10 PC. I installed Jenkins 2.89.2, Visual Studio 2017 and Python 3.6 and copied several Jenkins jobs from my previous Windows 7 PC.
The problem that I encountered was that all the python scripts in the free-style Jenkins jobs now do nothing.
I have similar command-line batch files which run these python scripts which work just fine in a command window on the new PC.
I have also checked the file associations with ftype, and ended up changing it:
ftype Python.File
Python.File="D:\Python36_64\python.exe" "%L" %*
My work-around is like this:
Example line which worked under Windows 7:
CreateBuildNumber.py <= uses PATH to find this file, then file associations to run python
Replacement line need to work under Windows 10:
python .\Scripts\CreateBuildNumber.py <= uses PATH to find python.
How can I avoid explicit paths in my scripts?
Update:
D:\project>assoc | findstr -i python
.py=Python.File
.pyc=Python.CompiledFile
.pyd=Python.Extension
.pyo=Python.CompiledFile
.pyw=Python.NoConFile
.pyz=Python.ArchiveFile
.pyzw=Python.NoConArchiveFile
echo %PATH%
D:\Python36_64;D:\Python36_64\Scripts;.\Scripts;"C:\Program Files\CppCheck";C:\windows\system32
Further Info
I removed .\Scripts from the %PATH% and re-ran the job, having also moved demo.py into .\Scripts, now instead of doing nothing there is the error:
'demo.py' is not recognized as an internal or external command, operable program or batch file.
This means that Windows IS looking for and finding python scripts, but is failing to execute them. Why would windows not take the next step and use file associations to find an executable program to run, taking the file as a parameter?
Update:
Now everything works as it should and I don't know why.
I recently started using a different job on Jenkins that I had neither run nor touched for over two years and that one just worked without modification. I have since gone back over the job in question and reverted all the changes and this one works as well.
My guess is that Windows 10 has been patched.
The fact that "demo.py" gives the message '...is not recognized as an internal or external command' doesn't convince me that your script is recognized as executable. If I type 'turkey.abc' into a command prompt window I get the same error, and I don't have a tool for executing '.abc' files.
I see two possibilities here:
1) In batch scripts, executable extensions sometimes must appear in an environment variable called PATHEXT.
In the Jenkins batch script, add a "set" command near the top of the script to dump the environment variables for your running script into your Jenkins build log (you can remove the set command after this is debugged). Run the build. Look not only for the definition of PATH, but also at PATHEXT. Is ".py" one of the extensions listed there?
I have experienced this problem with Perl scripts. However, I'm wimping out on claiming this definitely since in testing on my Windows 10 home PC I am successfully executing .py scripts even without it being in PATHEXT, so it's something to try but it may not be this.
2) Another possibility is that the environment in which your service is running is different than the environment you get when you open a command prompt on your desktop (because the Jenkins service runs as a different user than the one you log in as.)
Adding "set" to your Jenkins batch commands will help debugging this too, since it will show you the environment your Jenkins script is running in. Then you can examine PATH to see if your script folder is being found.
It is also possible that the file associations for Python were installed for your user only, not for all users (i.e., in HKEY_CURRENT_USER in the registry instead of HKEY_LOCAL_MACHINE). That is harder to dump into your Jenkins log - the 'reg' command would do it, but it will take you a number of tries to get everything you need. You might be able to figure it out by just examining the registry. Search for ".py" - if it occurs in HKEY_LOCAL_MACHINE that is not it; if it occurs in HKEY_CURRENT_USER that is at least part of the problem.
I don't know if this will fix your issue but you shouldn't have a relative path in your PATH environment variable.
Can you try again after having removing .\Scripts from the PATH variable? (don't forget to open a fresh new terminal do get the new %PATH% value)
The problem is that your PATH variable doesn't include the paths of you python scripts. You need the full path of the Scripts directory. Not the relative path .\Scripts.
Related
I was trying to run a Python script via Mac's Automator and the command is very straight forward:
"cd /Users/myname/Desktop/project && python3 myprojectapp.py".
However, every time I tried to run it, Automator raised an error such as ModuleNotFoundError. This was however, impossible since I had all libraries (e.g. Pandas) installed and running the command in the Terminal as written above worked flawlessly.
Now, I've read somewhere for a similar problem to just include:
"export PATH=/usr/local/bin:$PATH" before the command and it worked. Now, before I go on with my life, I would like to understand what exactly this extra line does and how it affects Automator to the point of making the script work.
Thank you in advance!
That command basically modifies the environment variable PATH and puts the directory /usr/local/bin before everything that is currently in PATH. However, that command is temporary, and the environment variable PATH is restored when the session closes.
What could be happening is the python you're running in terminal and the python Automator is running are different./usr/local/bin probably contains the same python version as you are using in terminal. Take a look at ~/.bash_profile to see if something similar to export PATH=/usr/local/bin:$PATH is in there.
Another way to check is to type which python in both and see if it points to the same python. You probably have yet another python somewhere in the list of directories in your PATH variable.
It's common to use virtual python environments to keep track of which python is running and to experiment with python without messing with system python. Examples of these include: Anaconda and virtualenv.
I am running Windows 10. I have recently changed location to my python folder and interpreter.
Unfortunately, when i now run python scripts in command prompt, I always have to type "python" before the name of the script I want to run.
Running the script directly - for example: C:\Python 37\mypythonscript.py -generates absolutely no reaction from the command prompt. I simply get back directly to C:\Python37>
If I however run C:\Python 37\python mypythonscript.py, the script is properly executed.
I have changed all the file associations using "ftype" and "assoc" in the command prompt. When I start command prompt and type "python", the python compiler correctly starts.
My problem is that I always have to type "python" before the name of my script for the command prompt to recognize that it needs to execute python.
I would like to open command, change directory to the directory with my python scripts, and simply run the python scripts by running the name of the scripts (mypythonscript.py) without having to type "python" in front of it.
Could you please help me identify what is wrong? How can I once again run python scripts in the command prompt without having to type "python" in front of the script's name?
Thank you in advance.
If you use a python 3 Virtualenv in powershell the above problem can be very confusing. Typically "py .\yourscript.py" or "py .\yourscript" will work but ".\yourscript.py" or ".\yourscript" will fail and might return a "ModuleNotFoundError: No module named '<module>' " error.
This happens because your .py association is not correct as described by Eryk Sun in the above second remark. The "py launcher" he names is, in most cases, "C:\Windows\py.exe". I my case it was already installed and I just needed to adjust the .py extension as described by him. It can also be done via the "Choose default apps by file type" settings.
A useful help is to define "$env:PYLAUNCH_DEBUG=1" in your powershell. After that "py .\yourscript.py" will have extra output showing where your python executable is found.
If there is no extra output it means, as before, that you don't have ".py" associated with "py.exe". If you start a "cmd" and "ftype python.file" looks ok, you need to read Eryk Sun's first remark :-)
I have python.exe installed on my machine (several times) but no python.bat. I'm trying to build Chromium Embedded Frameworks and the master batch file says
#echo off
python.bat tools\gclient_hook.py
but python.bat not on my machine giving error 'python.bat' is not recognized as an internal or external command,operable program or batch file.
Is there a python scripting edition or something?
UPDATE: SO User R-nar was correct, needed stripping off .bat
This is not my code but part of Chromium Embedded Frameworks.
cef_create_projects.bat
Ok, so after fixing I am running into Python 2 errors. It looks like python.bat may have been an indirection mechanism to keep the Python 2 scripts working.
You have to use python.bat from depot_tools, see step 2 here:
https://bitbucket.org/chromiumembedded/cef/wiki/MasterBuildQuickStart#markdown-header-windows-setup
Download depot_tools.zip and extract to "c:\code\depot_tools". Do not use drag-n-drop or copy-n-paste extract from Explorer, this will
not extract the hidden ".git" folder which is necessary for
depot_tools to auto-update itself. You can use "Extract all..." from
the context menu though. 7-zip is also a good tool for this.
Check if have the the directory of python.bat in your environment path variable, otherwise python.bat must me in the current working directory.
I am trying to access Python through a Windows command prompt, but am at an office and cannot add an Environment Variable. So, I cant follow the advice provided here. Thus, I added a User Environment Variable through User Accounts and use Variable:python and Value: C:\Python33. When I do a Windows Run check on %python% I reach the required Python33 folder. However, when I type python -Version in the command prompt I get the error 'python' is not recognized as an internal or external command, operable program or batch file. I am not sure how to proceed.
Run Python from the command prompt and include the full path to python.exe. For example to get the version:
C:\Python33\python.exe --version
When you run a script you specify the path to the script if you're not in the directory where the script is located. For example, if your script is in C:\scripts and is called my_script.py:
C:\Python33\python.exe C:\scripts\my_script.py
Instead of setting environment variables, you can use the whole path, like Neo wrote e.g.:
C:\Python33\python.exe yourPythonScript.py
Remove any environment variables you have added.
C:\Python33\python.exe pyscript.py should work.
I once Had a similar problem, but i couldnt find any solution, not even adding the path to the python folder was working.
Then I opened Python and clicked in File, then browser path, and I found that I had another folder that contained the real Python folder, not the default one. Maybe it could work for you too.
i've installed py 2.7 (64bit) on my PC with Win7 (64bit) without problem but I'm not able to run *.py scripts via DOS shell without declare python full path.
Let me better explain :
If I type D:\ myscript.py it doesn't work. The script is open with wordpad
If I type D:\ C:\Python27 myscript.py it works and run correctly
I try to change the default application software for *.py file via Win7 GUI ( control pannel etc etc) but without success.
Python is not present in the list of available sw and in any case also with the manual set I'm not able to associate python.exe at *.py files.
I've checked in my environment variables but I've not found problem (python path is declared in Path = C:\Python27\;C:\Python27\Scripts).
I've tried also to modify HKEY_CLASSES_ROOT->Applications->python.exe->shell->open->command :
old register value "C:\Python27\python.exe" "%1"
new register value "C:\Python27\python.exe" "%1" %*
without success.
Any suggestion?
Thanks
Here is another check to make, which helped me figure out what was going on.
I switched from the 32bit Anaconda to the 64bit version. I deinstalled, downloaded then reinstalled, but several things didn't get cleaned up properly (quick launch stuff, and some registry keys). The problem on my side was that the default installation path changed, from C:\Anaconda to C:\Anaconda2.
I first tried the assoc and ftype tricks, everything was fine there. However, the HKEY_CLASSES_ROOT\Applications\python.exe\shell\open\command registry key was pointing to the old Anaconda path. As soon as I fixed this, python.exe showed up when I tried associating with "Open with" and everything went back to normal.
I also added the %* at the end in the registry key.
You could try to use the ASSOCIATE command in CMD:
ASSOCIATE .py C:\PathTo\python.exe
More information at http://ss64.com/nt/associate.html
#slv 's answer is good and helped me a bit with solving this problem. Anyhow, since I had previous installations of Python before this error occured for me, I might have to add something to this. One of the main problems hereby was that the directory of my python-installation changed.
So, I opened regedit.exe and followed these to steps:
I searched the entire registry for .py, .pyw, .pyx and .pyc (hopefully I did not forget to mention any here). Then, I radically deleted all occurrences I could find.
I searched the entire registry for my old python-installation-path (e.g. C:\Users\Desktop\Anaconda3). Then I replaced this path with my new installation path (e.g. C:\Users\Desktop\Miniconda3). Thereby, I also came across and replaced HKEY_CLASSES_ROOT\Applications\python.exe\shell\open\command which #slv mentioned.
Afterwards, it was possible again to connect a .py-file from the Open with...-menu with my python.exe.
The *.py file is a source code file. If you set up your system environment correctly, you need to run python myscript.py
the following answer is related to your question
Making Python scripts run on Windows without specifying ".py" extension
Do you know that when you change the default application of a file, you are able to browse for the application?
You can click on the "browse" button (as shown in the red rectangle), then choose C:\Python27\python.exe.
Also remember to click on the "Always use this program to open this program" checkbox, which is shown in the green rectangle, so that win7 knows how to open this file the next time you ask it to open *.py file.
Then I believe you'll be able to run myScript.py simply by typing "myScript.py" in the correct dirctory in DOS shell.
After doing all the above steps, be sure to reopen a new command shell.