I have just moved to Linux (Ubuntu 15.04) and I am trying to add my python directory (:~/Documents/Python/Programs) to the path variable, but I am struggling..
I have tried export PATH = $PATH:~/Documents/Python/Programs, and then turning off and on again, but nothing happens
I have also looked at my ~/.profile, but don't under stand it, it comes up with (I have removed a tonnes of comments from the top):
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
PATH="$HOME/bin:$PATH"
fi
UPDATE:
What I am trying to do is add my python directory to PATH so that I will be able to import self made modules from within this directory
I was under the impression I had to add this to PATH by adding
PATH="$HOME/Documents/Python/Programs/:$PATH"
To the bottom of my ~/.profile document, was this wrong, and what should I actually be doing to solve this?
You have to set your PATH e.g. inside ~/.profile or ~/.bashrc depending on where you want to use Python. Add something like this to the end of either of them:
PATH="$HOME/Documents/Python/Programs/:$PATH"
As stated by the comments, this change will only be take into account, after either restarting a login shell or new start of X session (e.g. newboot). If you need the changes directly, either source the file or export it manually... so
either
source ~/.profile
source ~/.bashrc
(you could also use the . operator, but this is only working in Bash)
or export the variable
export PATH="$HOME/Documents/Python/Programs/:$PATH"
It's important to add your custom path before original PATH as the shell will call the 1st file found inside $PATH.
Related
I have installed virtualenv and the virtualwrapper via apt-get, I got to a point where I created a virtual enviroment but however later on during that same day when I used the workon command it was not found. I further on went and inspected my home directory and .virtualenvs dir and the virtualenv I created earlier were still there.
Solving this problem took two steps:
Add this to your .bashrc / .bash_profile / .zshrc:
# load virtualenvwrapper for python (after custom PATHs)
venvwrap="virtualenvwrapper.sh"
/usr/bin/which -s $venvwrap
if [ $? -eq 0 ]; then
venvwrap=`/usr/bin/which $venvwrap`
source $venvwrap
fi
Then use:
source .bash_profile
# or .bashrc / .zshrc
to reflect the changes.
Additionally, if the terminal still sometimes cant find workon, use source .bash_profile to reset and find it again.
type source .profile in home directory from terminal.
Read the readme in the top of which virtualenvwrapper.sh
You need to source it inside bashrc
open ~/.profile
cd ~
nano .profile
add at the end
#virtualenvwrapper setup
export WORKON_HOME=$HOME/envs
export PROJECT_HOME=$HOME/dev
source /usr/local/bin/virtualenvwrapper.sh
to load your .profile file you just edited:
$ . .profile
I ran in to this problem too and I simply needed to logout and log back in.
This read in the changes which the debian package manager made to my system at /etc/bash_completion.d/virtualenvwrapper
I have few conda environments that I use in different projects, say:
ml37 (for machine learning)
etl37 (for data pipelines)
I have local projects organized in their own directories:
apps/some_app
apps/other_app
...
Each time I cd to a specific project, I already know which env I would like to use. So I end up doing conda activate [some env] each time I change directories. I feel like there must be a better way.
What would be a clean way to automatize this?
Or is my use of conda environments wrong?
I made a script similar to the one of Corey Chafer, but this one extends the cd command.
cd() { builtin cd "$#" &&
if [ -f $PWD/.conda_config ]; then
export CONDACONFIGDIR=$PWD
conda activate $(cat .conda_config)
elif [ "$CONDACONFIGDIR" ]; then
if [[ $PWD != *"$CONDACONFIGDIR"* ]]; then
export CONDACONFIGDIR=""
conda deactivate
fi
fi }
Put this few lines of code at the bottom of your shell profile and then create a .conda_config file inside the directory you want to activate the env for.
The .conda_config file must contain only the env name.
In this way, every time you cd into a directory that has a .conda_config file, the script will activate the env, and every time you cd out it will deactivate.
I created a repo for reference Conda-autoactivate-env
EDIT:
There was a bug in the elif condition.
Basically [-n $CONDACONFIGDIR] returns always True and its logic is backwards actually.
The fix is:
quote the variable (or use double squared brackets) and remove -n
[ "$CONDACONFIGDIR" ] OR [[ $CONDACONFIGDIR ]].
The above code is already up-to-date!
The mssql-cli uses the following bash script to execute the actual python script. As I understand the code, the while loop determines the current directory of the script executed, this path gets then added to PYTHONPATH.
There are no .py files in the current directory so why is the path added to PYTHONPATH? Could someone please explain to me what the first part of the script is doing. Thank you for helping me out here.
#!/bin/bash
SOURCE="${BASH_SOURCE[0]}"
while [ -h "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink
DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )"
SOURCE="$(readlink "$SOURCE")"
[[ $SOURCE != \/* ]] && SOURCE="$DIR/$SOURCE" # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
done
DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )"
# Set the python io encoding to UTF-8 by default if not set.
if [ -z ${PYTHONIOENCODING+x} ]; then export PYTHONIOENCODING=utf8; fi
export PYTHONPATH="${DIR}:${PYTHONPATH}"
python -m mssqlcli.main "$#"
Wonder if this is still relevant for you, but I've marked it as fun puzzle to revisit later... Long story short: It adds directory of location where this script file is with all symbolic links resolved (neither the acquired filename nor a directory leading up to is is a symbolic link) to PYTHONPATH.
It's basically the same thing as doing so using readlink (or realpath):
export PYTHONPATH="$(dirname $(readlink -f ${BASH_SOURCE})):${PYTHONOATH}"
Line by line dissection:
SOURCE="${BASH_SOURCE[0]}"
This sets SOURCE to be path with which this script was called or sourced.
while [ -h "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink
We enter the wile loop if SOURCE path refers to a symbolic link. I.e. in the first iteration of this file was a symbolic link. Subsequently if this was a link pointing to another link.
DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )"
This (a bit simplified explanation of -P) changes into directory where SOURCE is resolving symbolic links along the way (i.e. lands in the directory the link(s) was/were pointing to) and prints working directory after that change (absolute path). All that happens in a subshell and result is assign to variable DIR.
SOURCE="$(readlink "$SOURCE")"
SOURCE is assigned a new value of path resulting from symlink resolution. Literally a target the link points to (as seen by for instance ls -l) relative or absolute.
[[ $SOURCE != \/* ]] && SOURCE="$DIR/$SOURCE" # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
If the SOURCE value we have obtained by symbolic link resolution does not begin with / (i.e. is an absolute path), DIR (directory where the SOURCE with which we have entered the loop resides) and resolved symbolic link SOURCE are concatenated over / to form a new SOURCE (we make it into an absolute path) and we go back to the top of this loop. NOTE: escaping of / by \ seems in this case unnecessary and arbitrary.
done
When done. SOURCE points to a file that is not a symblic link. It's path may still contain symbolic links at this point which is taken care of in the next step.
DIR="$( cd -P "$( dirname "$SOURCE" )" && pwd )"
Once more, like in the loop. DIR should now be pointing to a directory where resolved (not a symlink) SOURCE file (target of what was originally called/sourced) resides.
# Set the python io encoding to UTF-8 by default if not set.
if [ -z ${PYTHONIOENCODING+x} ]; then export PYTHONIOENCODING=utf8; fi
Exports an environmental variable if a shell variable was not set or equals to an empty string. NOTE: ${PYTHONIOENCODING+x} seems to be an alternative form of ${PYTHONIOENCODING:+x} and its use seems absolutely arbitrary. There is also a test to check if variable was set (regardless of its value).
export PYTHONPATH="${DIR}:${PYTHONPATH}"
PYTHONPATH is now set to start with an absolute resolved path (no symbolic links should be anywhere along the path) of where does this very script (or file this link points to) reside.
python -m mssqlcli.main "$#"
Calls python...
I trying to setup virtualenvwrapper in GitBash (Windows 7). I write the next lines:
1 $ export WORKON_HOME=$HOME/.virtualenvs
2 $ export MSYS_HOME=/c/msys/1.0
3 $ source /usr/local/bin/virtualenvwrapper.sh
And the last line give me an error:
source /usr/local/bin/virtualenvwrapper.sh
sh.exe: /usr/local/bin/virtualenvwrapper.sh: No such file or directory
I find, where on my drive is virtualenvwrapper.sh and change directory name. On my computer it's /c/Python27/Scripts/virtualenvwrapper.sh. When I again run command
$source /c/Python27/Scripts/virtualenvwrapper.sh
I get the next ERROR message:
sh.exe":mktemp:command not found ERROR: virtualenvwrapper could not create a temporary file name
I check my enviroment variable: C:\python27\;C:\python27\scripts\;C:\python27\scripts\virtualenvwrapper.sh\;C:\msys;C:\Program Files (x86)\Git\cmd;C:\Program Files (x86)\Git\bin\
I don't know where i made a mistake
The error is saying that sh.exe (the shell) can't find a command matching mktemp, which means it's not present in GitBash, at least not in your environment.
One option is you could download a Windows version of mktemp, such as http://gnuwin32.sourceforge.net/packages/mktemp.htm and then place it in the C:\Program Files (x86)\Git\bin directory. The shell should then be able to match the mktemp command and be able to proceed.
I've found a fix for this problem on a Windows 8 machine using GitBash.
TL;DR:
Get mktemp for windows, put it somewhere that can be used by GitBash, then edit virtualenvwrapper.sh and on line 202, add a touch command with the file created. It should look like this:
file="$(virtualenvwrapper_mktemp -t virtualenvwrapper-$suffix-XXXXXXXXXX)"
touch $file # this is the new line
if [ $? -ne 0 ] || [ -z "$file" ] || [ ! -f "$file" ]
FULL ANSWER:
As khampson mentioned, you do have to download mktemp and place it where your Git\bin (C:\Program Files (x86)\Git\bin usually) directory is. After that, running the virtualenvwrapper.sh file would cause an error saying:
path = C:/Users/User/AppData/Local/Temp/virtualenvwrapper-initialize-hook-XXXXXX XXXX
lpPathBuffer = C:\Users\User\AppData\Local\Temp\
szTempName = C:\Users\User\AppData\Local\Temp\tmp23A9.tmp
path = C:\Users\User\AppData\Local\Temp\tmp23A9.tmp
fd = 3
ERROR: virtualenvwrapper could not create a temporary file name.
On line 202(source), you see a function call to virtualenvwrapper_mktemp (which is just a wrapper function to call mktemp) and this is supposed to create the new temp file, but apparently it doesn't on windows.
Going through the manual for mktemp, on the examples section, you see that they are always sending something to that new file handle which forces the file to be created.
So instead of sending an empty string using echo like the manual, just add a touch command to the virtualenvwrapper.sh:
file="$(virtualenvwrapper_mktemp -t virtualenvwrapper-$suffix-XXXXXXXXXX)"
touch $file # new command here
This should force windows to create the temp file. I can't post the rest of the links due to low rep but I hope this still helps someone.
EDIT
I created a pull request on the virtualenvwrapper repo and it got approved. You can see the touch command I suggested added here.
Is it somehow possible to programatically get the bin/Scripts directory path related to the current runtime environment? It's typically /usr/lib/pythonX.Y/bin (or C:\PythonXY\Scripts), but it can be different in e.g. virtual environments.
I'm aware of the constants in distutils.command.install, but I hope there is an easier way to get the path.
the virtual environment path is stored in the $VIRTUAL_ENV environment variable.
$VIRTUAL_ENV/bin/Scripts
will give you what you want if you have a virtual environment loaded. you can check to see if that virtual environment is set, and if not, fall back on the system runtime directory:
if [ -z "$VARIABLE" ]
then
dir=$VIRTUAL_ENV/bin/Scripts
else
dir=/usr/lib/pythonX.Y/bin/Scripts
fi
another thing you can try is to extrapolate the runtime directory from the output of the command 'which python', which would give you something like this:
$(which python | cut -d "'" -f 3 | sed 's/python$//')"Scripts"