So I installed Miniconda using Homebrew and then installed Spyder using Conda. Then I wanted to make the process more "Mac" friendly by creating an application which opens Spyder so I used the solution by topoman which is below the accepted answer in this link:
Ways to invoke python and Spyder on OSX
Everything works more or less fine except I have ran into two issues (the second one isn't really an issue and more of an aesthetic related thing):
I downloaded py files from this GitHub (https://github.com/realpython/python-scripts) just to test that it will open py files. It works for them and I am also able to set Spyder as the default application by using the "SpyderOpener" solution provided by topoman in the above link.
The issue is that when I create a new file in spyder and save it then try to click-open it, it won't. I'm not sure what the difference is and why the "SpyderOpener" does not work on this py file originating from Spyder, but works fine for the ones I downloaded.
I was curious if it is possible to change the display icon for py files that have the default as "SpyderOpener". I did change the icon for the SpyderOpener application but it doesn't work. The icons for the files is just a blank printer sheet.
UPDATE:
I believe I found the issue. It depends on where the file is. When I put it on my desktop, no issue. When I put it in other certain places no issue. Based on experimenting it seems that the opener does not work when the file is within a folder that has a space in the name (e.g. folder name). The minute I change to folder_name or foldername it works fine.
Therefore, is someone able to explain why the opener script breaks down when there is a space at any place in the file path? Can the script be edited to handle this?
Does it boil down to the following stack threads (i.e. I need to apply double quotes somewhere in the script):
Shell Script and spaces in path
https://askubuntu.com/questions/1081512/how-to-pass-a-pathname-with-a-space-in-it-to-cd-inside-of-a-script
This thread also suggests the script shouldn’t use the $# argument unquoted because it will break as soon as you have “spaces or wildcards”:
https://unix.stackexchange.com/questions/41571/what-is-the-difference-between-and
Therefore looking at the script and previous steps you have:
#!/bin/bash
/usr/local/bin/spyder $#
Then the opener script has:
for f in "$#"
do
open /Applications/spyder.app --args $f
done
if [ -z "$f" ]; then
open /Applications/spyder.app --args ~
fi
As for the rest of the script, I assume $f isn’t going to cause problems? Anyways, it seems the issue comes from the initial setup?
Based on this, it should be handled by the above line:
Handle whitespaces in arguments to a bash script
So is it breaking down because of the args?
Related
I have several python scripts which work just fine but one script has (as of this morning) started giving me this error if I try to run it from the bash:
: No such file or directory
I am able to run the 'broken' script by doing python script_name.py and after looking around a bit the general idea that I picked up was that maybe my line ending of the hashbang got changed (silently) so I looked at the line ending of a working script and a broken script via the :set list option in VI as indicated in this question -> View line-endings in a text file
Both files appear to end using the same character (a $) so I am kind of at a loss on how to proceed from here. Specifically, how to actually 'see' the line ending in case the set list was not the right method.
PS: The script is executable and the shebang is in there, I stated that it's just this 1 script that was working fine before the weekend but it started giving me this error as of this morning.
-- edit: --
Running the script through dos2unix does get it working again but I would like to know of any way to visualize the line ending somehow in VI(M) or why Geany somehow converted the line endings in the first place (as I never work on a dos/windows system anyhow).
From the comments above it looks like you have dos line endings, and so the hashbang line is not properly processed.
Line ending style are not shown with :set list in Vim because that option is only used when reading/writing the file. In memory line endings are always that, line-endings. The line ending style used for a file is kept in a Vim per-file option, weirdly called fileformat.
To see/change the line ending style from Vim, you can use the following commands:
:set fileformat
:set ff
It will show dos or unix. You want unix, of course ;-).
To change it quickly you can save the file with:
:w ++ff=unix
Or if you prefer:
:set ff=unix
And then save the file normally.
So see all the gory details just do :help fileformat, :help file-formats and :help fileformats
You can also use the dos2unix command to convert the file format
dos2unix
This helped me to run the python scripts
This normally happens when we open files in windows do changes and save it.
if you open the file locate the ^M characters at the end of every line
Thanks
Personally, I find it kinda wrong using direct path to python interpreter. As you dont use windows platform, you should have program env, usually in /usr/bin (/usr/bin/env). Try using following shebang:
#!/usr/bin/env python
Different distros store python binary in /bin or /usr/bin (or some weird locations), and this one makes your script config-independent (as far as possible, here we have possibility that env is stored elsewhere; still - it is less possible that env is not in /usr/bin than that python is mislocated).
I had similiar problem (if not exactly the same) and that worked for me.
Also, I have both python interpreters (2.7.x and 3.x) installed, so I need to use "python3" argument for env. AFAIR usually distros link different names to different binaries, so "env python" will run python2.7 on my system, "env python3" (also python33, or smth like that) will run p3k, and "env python2" (also python27, etc) will run python 2.7.x. Declaring which version of interpreter should be used seems like a good idea too.
I came across this problem editing my code on Windows, checking it in with git, and checking out and running it on Linux.
My solution was: tell git to Do The Right Thing. I issued this command on the Windows box:
git config --global core.autocrlf true
Modified the files and checked them in; voila, no such problem any more.
As discussed on the Git documentation.
I am doing an application in Excel and I'd like to use python language. I've seen a pretty cool library called xlwings, but to run it a user need to have python installed.
Is there any possibility to prepare this kind of application that will be launch from a PC without Python?
Any suggestion are welcome!
A small workaround could be to package your application with cx_freeze or pyinstaller. Then it can run on a machine without installing python. The downside is of course that the program tend to be a bit bulky in size.
no. you must need install a python and for interpreting the python function etc.
It is possible using xlloop. This is a customized client-server approach, where the client is an excel .xll which must be installed on client's machine.
The server can be written in many languages, including python, and of course it must be launched on a server that has python installed. Currently the .xll is available only for 32 bits.
This might not be exactly what you're looking for (i.e.- "without python"), but you could ship it as a virtualenv .zip folder with all the necessary packages and respective python installation included in the folder... and also include a run.command bash executable inside the folder that the user can click on to run your program. You'll have to tell the user (inside a README.txt or something) how to enable the executable... For a particular application mine looked like...
Please complete the following steps after installation of MyApplication.zip:
Step 1: Move the MyApplication folder to your Desktop.
Step 2: Open your Terminal in Go then Applications then Utilities.
Step 3: In the Terminal, paste cd ~/Desktop/MyApplication
then press Enter.
Step 4: Then, paste chmod +x run.command
then press Enter.
From now on, clicking the “run” file in MyApplication will run the application.
If clicking the “run” file still doesn’t work, then do…
Click Ok on the popup then Open System Preferences then Security & Privacy
then Click on Open Anyway button then Click Open button on the popup.
NOTE: Please do not move or delete the MyApplication folder, or any of its files.
Then my run.command executable looked like the following:
cd ~/Desktop/MyApplication
PATH=$PATH:$HOME/Desktop/MyApplication/lib/python2.7/site-packages:$HOME/Desktop/MyApplication/lib/python2.7/site-packages/aeosa:$HOME/Desktop/MyApplication/lib/python2.7/lib-dynload:$HOME/Desktop/MyApplication/lib/python2.7/lib-old:$HOME/Desktop/MyApplication/lib/python2.7/lib-tk:$HOME/Desktop/MyApplication/Extras/lib/python:$HOME/Desktop/MyApplication/lib/python2.7/plat-mac/lib-scriptpackages:$HOME/Desktop/MyApplication/lib/python2.7/plat-mac:$HOME/Desktop/MyApplication/lib/python2.7/plat-darwin:$HOME/Desktop/MyApplication/lib/python2.7:$HOME/Desktop/MyApplication/lib/python27.zip
source bin/activate
python main.py
Three things are important here:
1) In run.command, I first change directory into the virtualenv I created for this project. I'm not trying to be dynamic here, since this is all just a quick hack of a solution, so as part of the README.txt, I simply tell the user to put the folder they downloaded onto their desktop. Otherwise, the cd command wouldn't work.
2) I set the client's PATH variable, separating entries with colons. You can see a list of the paths you'd need using a quick check on your computer...
import sys
for path in sys.path:
print path
3) I then call source bin/activate to activate the virtualenv.
4) I then execute my main.py file, which is in the top level of my virtualenv, along with run.command.
5) I only wrote this bash file for Mac OS X, so I don't know how it would translate to windows PCs. I think the only thing that'd change is that the path literals would need to use backslashes instead of forward slashes, but again, I haven't done this for windows so I'm uncertain.
Read more about setting up a virtualenv here: https://virtualenv.readthedocs.org/en/latest/index.html
Finally, note that you will not be able to send your final, working .zip folder over most email services, since they tend to prevent people from sending executables back and forth, so you'll have to use a service like Dropbox or something to send it to people.
In Windows 8, I often use the Python Windows Launcher like
py C:/long/long/long/long/long/path/to/prog.py ...
Is there any way to set some environment setting, such as PATH or PYTHONPATH etc, to prevent having to type the full path to prog.py?
From my basic knowledge/research, PATH only helps with the py part of the command line and PYTHONPATH only helps with imports within prog.py, so how do I deal with the path to prog.py itself??
Notes:
I cannot modify the code, not even the "shebang" line, since it is needed to work on other platforms.
I cannot cd to the directory containing the programs to run them, because the programs will do something based on the directory they're run in (they'll modify the files in the directory they're run in).
I know that if I associate .py extension with the Python Windows Launcher, then I can run prog.py as the first item in the command line, and thus use PATH, but currently my .py extension is associated with my favorite editor and I'd like to keep it that way if possible (so I can double-click any Python file in Windows Explorer and edit it).
However, if someone suggests a solution where I can have a different association for Windows Explorer versus the command line, then that could be a potential solution! (i.e. in Windows Explorer, .py opens with the editor, while on command line, .py runs with Python Windows Launcher)
Add your long path to PYTHONPATH, then invoke your program as such:
python -m prog
Python will search for a module called prog and then run it as the main module.
Answer to my own question: Actually, I'm so silly. I could just set a variable for each program path (there are only a few programs paths), i.e.. prog=C:/long/path/to/prog.py and then do py %prog% .... I guess I figured out an answer to my own question that was acceptable to me.
Update: I just found something even better. I can do
doskey prog=py C:/long/path/to/prog.py $*
and then simply prog ... afterward
Now I just have to do some crazy stuff to get the doskey command into a file that will be run every time I start a console, as described here: https://stackoverflow.com/a/21040825/5182136
I have several python scripts which work just fine but one script has (as of this morning) started giving me this error if I try to run it from the bash:
: No such file or directory
I am able to run the 'broken' script by doing python script_name.py and after looking around a bit the general idea that I picked up was that maybe my line ending of the hashbang got changed (silently) so I looked at the line ending of a working script and a broken script via the :set list option in VI as indicated in this question -> View line-endings in a text file
Both files appear to end using the same character (a $) so I am kind of at a loss on how to proceed from here. Specifically, how to actually 'see' the line ending in case the set list was not the right method.
PS: The script is executable and the shebang is in there, I stated that it's just this 1 script that was working fine before the weekend but it started giving me this error as of this morning.
-- edit: --
Running the script through dos2unix does get it working again but I would like to know of any way to visualize the line ending somehow in VI(M) or why Geany somehow converted the line endings in the first place (as I never work on a dos/windows system anyhow).
From the comments above it looks like you have dos line endings, and so the hashbang line is not properly processed.
Line ending style are not shown with :set list in Vim because that option is only used when reading/writing the file. In memory line endings are always that, line-endings. The line ending style used for a file is kept in a Vim per-file option, weirdly called fileformat.
To see/change the line ending style from Vim, you can use the following commands:
:set fileformat
:set ff
It will show dos or unix. You want unix, of course ;-).
To change it quickly you can save the file with:
:w ++ff=unix
Or if you prefer:
:set ff=unix
And then save the file normally.
So see all the gory details just do :help fileformat, :help file-formats and :help fileformats
You can also use the dos2unix command to convert the file format
dos2unix
This helped me to run the python scripts
This normally happens when we open files in windows do changes and save it.
if you open the file locate the ^M characters at the end of every line
Thanks
Personally, I find it kinda wrong using direct path to python interpreter. As you dont use windows platform, you should have program env, usually in /usr/bin (/usr/bin/env). Try using following shebang:
#!/usr/bin/env python
Different distros store python binary in /bin or /usr/bin (or some weird locations), and this one makes your script config-independent (as far as possible, here we have possibility that env is stored elsewhere; still - it is less possible that env is not in /usr/bin than that python is mislocated).
I had similiar problem (if not exactly the same) and that worked for me.
Also, I have both python interpreters (2.7.x and 3.x) installed, so I need to use "python3" argument for env. AFAIR usually distros link different names to different binaries, so "env python" will run python2.7 on my system, "env python3" (also python33, or smth like that) will run p3k, and "env python2" (also python27, etc) will run python 2.7.x. Declaring which version of interpreter should be used seems like a good idea too.
I came across this problem editing my code on Windows, checking it in with git, and checking out and running it on Linux.
My solution was: tell git to Do The Right Thing. I issued this command on the Windows box:
git config --global core.autocrlf true
Modified the files and checked them in; voila, no such problem any more.
As discussed on the Git documentation.
Yes, I've searched. So after spending about 4-5 hours struggling just to get Python files running, I recently stumbled over the solution to get it running through the environment variables like this: cmd -> python -> Python starts, yay yay
Since it didn't work to do it through the command line and similar I had to do it manually through the Windows interface. Now that it's working, however I cannot open .py files without typing out the full path like this: python C:\X\X\X\test.py which is obviously also starting to get annoying.
So now I'm trying to find out which variable I have to change (yet again) to only be able to type 'python test.py' and have it running. Sorry if I come off vague, but it's always a major pain to setup a new programming language for me and it kills my mood.
Thanks for help, it'll be really appreciated.
When you say
able to type 'python test.py'
I'm not sure exactly what you mean. Normally when the Python interpreter runs, it looks in the current directory for any source file that is named on the command line (unless you specifically name a location for the source file, as you've discovered). It seems from your previous statement:
python C:\X\X\X\test.py which is obviously also starting to get annoying
that your test.py file exists somewhere else.
What you might want to try is to change the current directory first, before running your script. In a command prompt window, type:
C:
cd \X\X\X
python test.py
(obviously substituting your actual path name). My apologies if you already know this.
To make python executable on your command line, you need to add it to your PATH environment variable, which it sounds like you have done on the command line. It is quite simple to add directories to the PATH in Windows if you know where to look. Essentially, you need to get to the Environment Variables dialog box, which is slightly different for each version of Windows.
For Windows XP: Start -> Control Panel -> System -> Advanced -> Environment Variables
For Windows Vista, 7: Click the Start Orb, right-click Computer and select Properties -> Advanced -> Environment Variables
Then, in the lower of the two boxes, find Path and click Edit. Change it so that C:\Python27 (or whichever version of Python you have) is at one end of the list, separated from the other entries by a semicolon (e.g. C:\Python27;C:\Program Files ...)
Once you've done this, python will work at the command line whenever you open a command window.
Regarding your second issue, however, there isn't much you can do. You must either specify the complete path to your script or already be in the same directory as the script. That is, if the script is in C:\X\X\X you will either need to invoke it as C:\X\X\X\test.py or first cd C:\X\X\X.