I am trying to create an executable python script for use on the command line (aim is to upload to PyPi). For this I need to add a shebang.
On linux I have #!/usr/bin/env python3
For windows I need #! python3
How do I get the appropriate shebang for the different OS's?
Side note: I looked at an example of an executable file (cookiecutter) I have in a conda environment. I noticed the shebang was
#!/home/<my-name>/miniconda/envs/<some-environment>/bin/python3.6
Is Conda do something smart here? What about pip?
The Linux shebang works just fine on Windows with modern versions of Python and its dedicated py.exe launcher. Just use the Linux shebang consistently. Conda's shebang is designed to launch a very specific Python installation; in general, you want to use the default up-to-date Python 3 install, and the PATH lookup approach on Linux (and emulation on Windows) is what you want.
use setuptools console_scripts feature.
It will generate the shebang for you
Related
Just curious, is there a particular reason why Python 3.x is not installed on Windows to run default with the command line "python3", like it does on Mac OSX and Linux? Is there some kind of way to configure Python so that it runs like this? Thanks.
EDIT: Just to add, the reason I am asking is because I have both the Python 2 and 3 interpreter installed on my computer, and so it is ambiguous, as both are run using the command "python".
the reason I am asking is because I have both the Python 2 and 3 interpreter installed on my computer, and so it is ambiguous, as both are run using the command "python".
To run Python 2 executable:
C:\> py -2
To run Python 3 executable:
C:\> py -3
where py is a Python launcher that is bundled with your Python 3 installation.
py recognizes the shebang (e.g., #!/usr/bin/env python3 causes Python 3 executable to be run), it respects virtualenv (if you run py without specifying the explicit python executable version) i.e., run:
C:\> py your_script.py
and the correct python version is used automatically -- you don't need to specify the Python version on the command-line explicitly.
is there a particular reason why Python 3.x is not installed on Windows to run default with the command line "python3", like it does on Mac OSX and Linux?
OSX and Linux have python executable installed by default as a rule and it refers to Python 2 version in most cases at the moment that is why you need a separate python3 name there.
There is no Python on Windows by default. And therefore any version that you've installed is just python (I guess). The recommended way to manage multiple python versions is to use the Python launcher.
Is there some kind of way to configure Python so that it runs like this?
If you want to type python3 some_script.py instead of py some_script.py or even just some_script (assuming .py is in %PATHEXT% and Python launcher is configured to run Python scripts (check assoc .py and ftype Python.File) -- the default) then create a bat-file e.g., python3.cmd and put it in %PATH%:
"C:\path to\Python 3.X\python.exe" %*
You likely missed the checkbox at the bottom of the installer.
Full documentation here: https://docs.python.org/3/using/windows.html
Then, I think you just run python, not python3 from the Command Prompt. The reason Unix systems have python3 is because python defaults to Python2.x in many systems.
You have to add the python bin folder to your path. You can do it manually but when you install python i remember you have an option to do that.
I work with multiple Python 2.x and 3.x distros on Windows. Some of them are "portable" - i.e. not recorded in the Windows registry, and therefore not accessible by the version-selector py.exe delivered with Python 3.3+. To save my sanity, I wrote SelectPython.bat which is available on bitbucket. It configures the PYTHONHOME, PYTHONPATH and PATH variables according to the target you give it (a relative or absolute path to the parent directory of python.exe). You can do so in a way that is sticky for the rest of your command-line session:
> SelectPython C:\Path\To\Desired\Version\Of\Python
> python
or transiently, i.e. to call a particular python command without otherwise affecting the environment of the shell you're calling it from:
> SelectPython C:\Path\To\Desired\Version\Of\Python python -c "import sys;print(sys.version)"
You may find it helpful.
I'm planning to install Anaconda3 for Python 3.4. Since by default, Mac OS X uses Python2, will install Anaconda3 change the default Python version for the system? I don't want that to happen since Python3 can break backwards compatibility. If it does change the default Python version, how can I avoid that?
Apple has a built-in system for managing multiple versions of software, and switching between them. But you don't even need to worry about that, because Anaconda installations are self-contained: Everything lives under the top Anaconda installation directory (probably /Applications/anaconda). The only effect outside this directory is that during installation, Anaconda will offer to modify the PATH variable in your .bashrc. If you agree, it will add one line at the end of your .bashrc, something like this:
PATH="/Applications/anaconda/bin:$PATH"
As you can see, Anaconda puts itself first in the system path. This means that typing python at the shell prompt will launch python 3, which may not be what you want. I run Anaconda 3.4 like this and have had absolutely no problems with my system, but I did need to modify my own executable python2 scripts that launched python like this:
#!/usr/bin/env python
This is a nice way to find python wherever it is, but in this case it will find python 3-- oops! Changing the above to #!/usr/bin/python or to #!/usr/bin/env python2 ensures that they continue to work correctly. In my experience this was not necessary with any of the system's own scripts; everything is already set up to find the right python.
Alternative 1: You could decline the PATH modification, and use Anaconda via the launcher. In that case there is no change to the rest of your execution environment. The launcher will start a special bash prompt with the anaconda environment activated, but execution in normal shells is completely unaffected. If you will continue to program a lot in python 2, this may be for you.
Alternative 2: A minimal-impact alternative is to put the anaconda directory last in your path:
PATH="$PATH:/Applications/anaconda/bin"
This ensures that non-anaconda binaries take precedence over anaconda, so python will start good old /usr/bin/python (that is, python 2). You can start anaconda's variant by typing python3, idle3, etc. I did not have IPython before I installed anaconda, so typing ipython finds the anaconda version.
No it won't, you can have multiple python installs, once you don't remove your system python or manually change the default you will be fine.
Couple of questions about Python under Windows:
shebang:
I thought i read somewhere that the shebang is supposed to work correctly under Windows but it doesn't for me. So
#!/usr/bin/env python
#!/usr/bin/env python3
import sys
sys.version
No matter what shebang I use above I always get 2.7.6 on a system where both 2.7.6 and 3.3.3 are installed
2.Unfortunately Python 3.3 is not named python3.exe like on linux/mac. I want to have the ability to use both versions. I have my path variable set to 2.7.6 version first because thats what I'll probably use the most which means if I just type python thats the version. Is there any way to better manage this rather than having to type the full path to the executable or maybe dynamically changing the path variable?
Since there isn't usually a /usr/bin directory on Windows systems, even if shebang lines worked that wouldn't. You would instead need something like #!C:\Python33\bin\python.exe.
As far as I know, however, the shebang line is a Unix kernel feature that isn't available on Windows. I'd be happy to be wrong.
You would do well to look at using virtual environments - that allows you to set up the correct interpreter for each project, and keep the dependencies for different projects separate.
I am using a module that can only be found in python 2.7, so when I run my script I have to specify python2.7 script instead of just script. I know there are bigger issues out there, but still I was wondering -
is it possible, when writing a python script, to set the interpreter to 2.7 by default?
Maybe by setting #! /usr/bin/env python for example?
Most unix environments will have the python2.7 executable, such that you can write:
#!/usr/bin/env python2.7
Obviously this doesn't help much on windows. You can also at least check the python version once you are started, although it won't help you run the later version if it is available:
import sys
print sys.version_info
...really do checks here...
Using the shebang is an appropriate way to specify this, yes. Find out where python2.7 is in your PATH using which python2.7. This is e.g. /usr/bin/python2.7. You then set the shebang:
#!/usr/bin/python2.7
Of course, this only works on those systems where Python 2.7 is available at this location :) This will also work on may systems: /usr/bin/env python2.7
Then make the script executable and fire it off using $ ./wonderful_python_script.py.
If you are using Windows, install Python 3.3, which features a new launcher that provides shebang support under Windows. This will give you a (finally!) sane and cross-platform way of explicitly specifying interpreter versions.
I have some small utility scripts written in Python that I want to be usable on both Windows and Linux. I want to avoid having to explicitly invoke the Python interpreter. Is there an easy way to point shebang notation to the correct locations on both Windows and Linux? If not, is there another way to allow implicit invocation of the Python interpreter on both Windows and Linux without having to modify the script when transferring between operating systems?
Edit: The shebang support on Windows is provided Cygwin, but I want to use the native Windows Python interpreter on Windows, not the Cygwin one.
Edit # 2: It appears that shebang notation overrides file associations in Cygwin terminals. I guess I could just uninstall Cygwin Python and symlink /usr/bin/python to Windows-native Python.
Read up on the Python Launcher for Windows in the docs, which was initially described in PEP 397. It lets
you define custom shebang configurations in "py.ini" (e.g. to use pypy),
and out of the box you can use virtual shebangs such as #!/usr/bin/env python3, or shebangs with real paths such as #!"C:\Python33\python.exe". (Quoting is required for paths containing spaces.) You can also add command-line options to a shebang. For example, the following shebang adds the option to enter interactive mode after the script terminates: #!/usr/bin/python3 -i.
The installer associates .py (console) and .pyw (GUI) script file types with the respectively named launchers, py.exe and pyw.exe, in order to enable shebang support for scripts in Windows. For an all-users installation, the launchers are installed to the Windows folder (i.e. %SystemRoot%). For a per-user installation, you may need to manually add the installation directory to PATH in order to use py.exe in the shell (*). Then from the command line you can run Python via py -2, py -3, py -2.6, py -3.3-32 (32-bit), and so on. The launcher is handy when combined with -m to run a module as a script using a particular version of the interpreter, e.g. py -3 -m pip install.
(*) The new installer in 3.5+ defaults to "%LocalAppData%\Programs\Python\Launcher" for a per-user installation of the launcher, instead of installing it beside "python.exe", and it automatically adds this directory to PATH.
Unless you are using cygwin, windows has no shebang support. However, when you install python, it add as file association for .py files. If you put just the name of your script on the command line, or double click it in windows explorer, then it will run through python.
What I do is include a #!/usr/bin/env python shebang in my scripts. This allows for shebang support on linux. If you run it on a windows machine with python installed, then the file association should be there, and it will run as well.
Short answer:
The easiest way is to install git for windows wich comes with GitBash. Then add shebang lines in your scripts to indicate they should be run with python when executed.
#!/usr/bin/env python
More info:
Unlike Cygwin, git bash uses your native windows applications and lets you use bash scripts without any configuration.
It will automatically treat any file with a shebang line as executable the same way Linux shells do.
eg: #!/usr/bin/env php or #!/usr/bin/env node or any other application you want will work as long as you add the paths to your windows ENV path.
You can edit env vars in windows by hitting start and typing env should be the first option.
Git bash also installs git and hooks it up with a credentials manager for you and makes it super easy to sign into 2fa-enabled svn services and a ton of other handy developer features.
Git bash is IMO a must on every developer's machine.
Another option:
Install WSL (Windows Subsystem for Linux) which will work the same.
WSL also lets you install native Linux versions of all your command line applications if you prefer.
Linux binaries will take precedence over windows ones if installed but you can still choose to run the windows version of commands any time you want by specifically adding .exe on the end.
Install pywin32. One of the nice thing is it setups the file association of *.py to the python interpreter.
sorry for open old topic.
I create one file py.cmd and place it in the C:\Windows\System32 folder
py.bat:
#(
#set /p shebang=
)<%1
#set shebang=%shebang:#! =%
#%shebang% %1 %2 %3 %4 %5 %6 %7 %8 %9
py.bat file explain:
Get the first line from *.py file
Remove shebang characters "#! "
Run python file using shebang python path
All windows python script must start with shebang line as the first line in the code:
#! c:\Python27\python.exe
or
#! c:\Python37\python.exe
Then run it:
cmd> py SomePyFile.py param1 param1 paramX
Not with shebang ... but you might be able to set up a file association, see this SO question which deals with Perl and the associated answers which will also be pertinent as there's known problems with Windows and stdin/out redirection...