We Keep Coding

How to create a .desktop file to launch a python script on linux?

I created a python script ExeMain.py that use virtualenv for dependence. So to launch this script using .desktop I made this command
Exec=sh -c 'source ~/PycharmProjects/ProBlog/venv/bin/activate; python ~/PycharmProjects/ProBlog/ExeMain.py;'
Which resulted with this error "sh: 1: source: not found" and followed by "ImportError"
Without the source command in .desktop file with all necessary modules installed in direct python environment it works fine (in other Linux machine). As it seams not to be a good practice i tried using venv. And as of the errors i could see than the import error is because source command is not executed.
When i launch the .desktop file it should execute the ExeMain.py file.

Standard versions of sh does not have the source command. Perhaps use /bin/bash instead? So it'd be written something along the lines of this:
Exec=/bin/bash -c 'source /home/username/PycharmProjects/ProBlog/venv/bin/activate && /home/username/PycharmProjects/ProBlog/venv/bin/python /home/username/PycharmProjects/ProBlog/ExeMain.py'
I also suggest three other changes: 1) the && operator so that it won't try to run python code until the activate is finished, 2) replace the ~ tilde with the full path in case the desktop environment doesn't properly expand it, and 3) put in the full path to the venv python so that it doesn't default to the system python. Some of these may not be necessary (depending on the system setup), but it doesn't hurt to be careful.

os.system does not look the programs that are in my path

I have a problem when calling programs inside a python script. The programs that are giving me problems are those that I have installed manually on my computer and then added them to path on .bashrc file. The programs that where installed using 'sudo apt-get install some_program' don't give me any problem
The programs where added to my .bashrc file as the following way:
#path to fastqc
export PATH=$PATH:/home/bioinfor3/bin/FastQC/
#path to fastx-toolkits
export PATH=$PATH:/home/bioinfor3/bin/fastx/
Inside my PyCharm, I am using the os module to call those programs the in the below manner:
os.system('fastqc seq.fastq')
And I get this error
sh: 1: fastqc: not found
I guess it has something to do with the sh path or something, but I am not able to make it work
EDIT:
If Pycharm is launched from the terminal, it inherits the bashrc file with my personal paths and it works

Presumably this is happening because you have modified your login environment to adjust your PATH, but this updated path isn't seen by the shell that's running PyCharm, or PyCharm appears to be nullifying it somehow.
You should first of all verify that
os.system('/home/bioinfor3/bin/FastQC/fastqc seq.fastq')
operates as you would expect (no reason why it shouldn't, but worth checking).
It seems from this answer that by default PyCharm doesn't use bash for its shell but tcsh. Therefore it isn't seeing the setting you are enforcing on bash.

When I use Pycharm run a python file(in fact it is my first use), always report error, for example: [duplicate]

I need to debug an py-script in PyCharm that makes use of unix binaries like "which, grep" and so on.
If I start the py-script from Terminal (bash), unix binaries are found and all works like expected.
If I start the script from PyCharm "Debug" or "Run", there seems to be no "PATH" set => the unix binaries were not found.
Am I missing sth.?

Add the PATH environment variable to your Run Configuration (Run->Edit Configurations…) like this: /usr/local/bin:$PATH

Create a new environment variable in your run configuration named PATH, and set it equal to the output of running echo $PATH on your command line. This will let you get around the issue.

I have had to manually symlink binaries that are in your PATH, but not in /usr/bin/. For example, scripts running 'ffmpeg' in pycharm will not see /usr/local/bin/ffmpeg but after symlinking will be able to see /use/bin/ffmpeg. This is a python subprocess issue (they don't consult your .bashrc as bash does).

Virtual Env on Mac with python 3.4

I am trying to get a django project up and running, and I have django running, but I am having trouble with python's virtualenv.
here is my error (on terminal open this shows up)
/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: No module named virtualenvwrapper
virtualenvwrapper.sh: There was a problem running the initialization hooks.
If Python could not import the module virtualenvwrapper.hook_loader,
check that virtualenvwrapper has been installed for
VIRTUALENVWRAPPER_PYTHON=/Library/Frameworks/Python.framework/Versions/2.7/bin/python and that PATH is
set properly.
Here is what My .bash profile looks like:
# Setting PATH for Python 3.4
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.4/bin:${PATH}"
export PATH
# Setting PATH for Python 2.7
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}"
export PATH
export WORKON_HOME=$HOME/.virtualenvs
source /Library/Frameworks/Python.framework/Versions/3.4/bin/virtualenvwrapper.sh
export PIP_VIRTUALENV_BASE=$WORKON_HOME
if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi
I am pretty new to command line stuff and virtual environments, so I might not know some "obvious" things I am doing wrong. Thanks.

First some basics of the command-line shell:
PATH is an environment variable that contains a list of filesystem directories. When you type a command such as ls, python or virtualenvwrapper.sh your shell will search each directory starting from the first one listed. To see your current PATH type:
$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
To see what a given command is going to resolve to the location of the program that is going to be run, use the which command:
$ which ls
/bin/ls
Now in your example you are first adding a Python 3.4 location to your PATH and then a Python 2.7 location. The latter location is going to be first on your PATH. So all your Python related commands are first going to try and run Python 2.7, if a command isn't found there, it next searches in your Python 3.4 installation.
You appear to have installed virtualenvwrapper for Python 3.4, but when you run virtualenvwrapper.sh from the line:
source /Library/Frameworks/Python.framework/Versions/3.4/bin/virtualenvwrapper.sh
You are explicitly running the virtualenvwrapper.sh installed for Python 3.4. This runs a python command where your Python 2.7 is run, which does not appear to have virtualenvwrapper installed, as shown by this error message:
/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: No module named virtualenvwrapper
If you tried removing the Python 2.7 location addition to your PATH and it didn't work, you have to remember that changes to your .bash_profile are not automatically reflected in your terminal. You have to create a new terminal session and that new session will read your new .bash_profile.
If you are trying to get the command virtualenv to resolve to two different Pythons, it's simply not possible. It will always resolve to one specific Python based on the ordering of the locations on your PATH. VirtualEnv does install alternate versions of the command with the version of the Python built into the name. Use the commands virtualenv-3.4 and virtualenv-2.7 to create virtual environments for each different Python.
The key to all of this is remembering that PATH is used to resolve to an absolute path location of a program this is run. Use the echo $PATH and which commands to help you understand how that final path is being resolved.
It may seem tedious, but typing out the full absolute path is always going to side-step the magic of PATH resolution:
$ /Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv
Try using smaller steps on your way to manipulating the path. Use just virutalenv-3.4 to make a Python 3.4 virtual environment and only bring in virtualenvwrapper as you need it and after your understanding of shell environments is more solid.
Finally, even pro's can get tripped up by playing games manipulating the path. You are ultimately trying to take a bunch of different application locations and flatten them all into one namespace. At some point conflicts can become unresolveable. A Python installation tool such as Buildout has it's own learning curve, but it hard-codes the absolute path to the python of each python script that it installs. Hard-coding absolute paths is the only way to deal with extreme corner cases such as having two builds of Python 3.4 side-by-side where you have two scripts which each need to run on two different builds of the same Python. Hard-coding absolute locations is also desirable in production environments, because then your application is immune to any changes to the bash shell. If you forget about a required ordering of your PATH, or another sysadmin tinkers with the PATH, you won't find your application breaking unexpectedly.

OSX: Setting Enthought python path in .bash_profile results in weird terminal behavior

I followed the knowledge base on adding this to the .bash_profile
PATH="~/Library/Enthought/Canopy_64bit/User/bin"
export PATH
When I then restart the Terminal, a lot of functions do not work anymore:
X:~ excuvator$ ls
-bash: ls: command not found
X:~ excuvator$ security
-bash: security: command not found
X:~ excuvator$ sudo
-bash: sudo: command not found
However, enpkg and cd still seem to be callable. If I remove that part, stuff works again. Does anyone have any insight to what is happening? I just want to get enpkg running...

You reset PATH, rather than adding to it, so bash doesn't know any place to look for commands other than the single directory you specified. Instead, use one of
PATH=$PATH:~/Library/Enthought/Canopy_64bit/User/bin
or
PATH=~/Library/Enthought/Canopy_64bit/User/bin:$PATH
Which of the two assignments you use depends on whether whether you want the new directory to be the first or last place the shell looks for a named command.
enpkg actually is in that directory, and cd is a shell built-in command, not an external program, so no path lookup is involved.