We Keep Coding

Issue Opening Py Files in Spyder Using Custom Automator Script

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?

Spyder running script with different working directory to script directory

I have set the Spyder 2.7 preferences as follows: Preferences->Run-> General Settings-> Default working directory is: the script directory.
However for a particular script, spyder sets the working directory to the parent directory.
I have scripts in the same directory which don't exhibit this behaviour and run with the expected wdir.
I don't understand where or how the wdir is being altered from the default for this particular script.

Under 'run' menu-> configure. This gives you an option to set the working directory for each individual script.

I don't have the solution, but I had the exact same problem with a MATLAB script a while ago. It turned out I ran a copy of the script, and it included the path of the original, and set that as the wdir. I ran the original, it worked. If I moved the original, it didn't run because it tried running it from the previous wdir.
I ended up copying the code into a new script-file, which solved it for me.
Perhaps you can try something similar.
Best of luck!

Python: runtime shebang problems

Here is the problem I am trying to solve. I don't have a specific question in the title because I don't even know what I need.
We have an ancient Hadoop computing cluster with a very old version of Python installed. What we have done is installed a new version (2.7.9) to a local directory (that we have perms on) visible to the entire cluster, and have a virtualenv with the packages we need. Let's call this path /n/2.7.9/venv/
We are using Hadoopy to distribute Python jobs on the cluster. Hadoopy distributes the python code (the mappers and reducers) to the cluster, which are assumed to be executable and come with a shebang, but it doesn't do anything like activate a virtualenv.
If I hardcode the shebang in the .py files to /n/2.7.9/venv/, everything works. But I want to put the .py files in a library; these files should have some generic shebang like #!/usr/bin/env python. But I tried this and it does not work, because at runtime the virtualenv is not "activated" by the script and therefore it bombs with import errors.
So if anyone has any ideas on how to solve this problem I would be grateful. Essentially I want #!/usr/bin/env python to resolve to /n/2.7.9/venv/ without /n/2.7.9/venv/ being active, or some other solution where I cannot hardcode the shebang.
Currently I am solving this problem by having a run function in the library, and putting a wrapper around this function in the main code (that calls the library) with the hardcoded shebang in it. This is less offensive because the hardcoded shebang makes sense in the main code, but it is still messy because I have to have an executable wrapper file around every function I want to run from the library.

I would change the environment variable PYTHONPATH and also the environment variable PATH. Point PYTHONPATH to your virtual environment and PATH to the directory that contains your new python executable, and make sure the path to your python executable comes first.

I accepted John Schmitt's answer because it led me to the solution. However, I am posting what I actually did, because it might be useful for other Hadoopy users.
What I actually did was :
args['cmdenvs'] = ['export VIRTUAL_ENV=/n/2.7.9/ourvenv','export PYTHONPATH=/n/2.7.9/ourvenv', 'export PATH=/n/2.7.9/ourvenv/bin:$PATH']
and passed args into Hadoopy's launch function. In the executable .py files, I put the generic #!/usr/bin/env python shebang.

Source file (.py) not compiling (.pyc not updated)

I'm trying to change some code in a production server, but when I test the new code it's not being executed. I think the issue is that when I upload the updated source file, it is not being compiled into a .pyc file.
-rw-r--r-- 1 ubuntu ubuntu 47872 Jul 13 04:39 admin_email.py
-rw-r--r-- 1 root root 48212 Feb 10 03:12 admin_email.pyc
As you can see from the timestamps above, the .pyc file has not been updated.
Am I correct in assuming the reason the changes in admin_email.py are not being applied is because it is not being compiled? If so, can someone please offer a suggestion on how to get it to do so? Could the issue be that I need to restart the server?

Resetting the application probably does the trick. Since you are using gunicorn/nginx I assume you are also supervisord (if this is not the case please say so, then I can update my answer to also add that). In that case you can do sudo suporvisorctl restart <app_name> to restart the application.
Another issue that might be there, as brainless coder and Marius also stated, is that it seems the application was (at least once) ran as root, you should avoid this. You should remove the .pyc files and change the user the application runs under.

The .pyc file is owned by the root user for some reason, and not writeable by other users. Your Python process probably runs as non-root, and can't create new .pyc files.
Either delete the old .pyc files (make a backup first), or chown them to the same user as the process that runs the .py files, and it will probably work.

You can delete it if needed but it's really not. I don't see how that's the reason your code isn't executing.
.pyc files are byte codes that the python interpreter compiles the source to, so as long as you have access to the .py file you're safe to delete.
Are you running the script through shell? Did you give the file executable (+x) permission before doing so?

How do I run code from a different directory with a bash script

I have been putting my code on github, but I've run into an implementation snag. I run the same code on many computers (including a computer that I do not have root access on).
One piece of code (a bash script) calls some python code like:
python somecode.py
The shell will run the correct version of python, but it won't find somecode.py.
What I've tried:
Fail #1: I tried to add both the directory which contains somecode.py and the full path to the file to the PATH; to no avail. [Errno 2] No such file or directory
Fail #2: I can make it work for one computer ONLY if I add the full path to the correct version of python in the top line:
#!/usr/local/cool/python/version/location
However this breaks it running on any other computer.
Fail #3: I can also make it work if I make the bash script say:
python /full/path/to/github/place/somecode.py
but again, this only works for ONE computer because the paths are different for different computers.
What I really want to do: I want to be able to use the same code (both bash script and somecode.py) on multiple computers.
Any suggestions about how to do this properly is welcome. Thanks!
Solution
Added:
#!/usr/bin/env python
To the top of my somecode.py code;
mv somecode.py somecode
chmod +x somecode
Make sure PATH has /full/path/to/directory/with/somecode.
Bash script now says only:
somecode
and it works.

For problem #2 try
#!/usr/bin/env python
though it may find different versions of Python on different machines, but as long as that's not a problem this should fix that particular problem
See this SO question Python deployment and /usr/bin/env portability too. And this post by Alex Martelli re use of this.

If you say python somefile.py then it will take the location of somefile.py as the current directory, not from $PATH. It will take the location of python from $PATH.
If you say somefile.py then it will take the location of somefile.py from $PATH, and the location of python from the #! line of your python script, which can use the PATH if you follow #Levon's suggestion.