Getting started
By the end of today we will have all the tools we need to do just about any and everything we want. I promise.
Step 1 - virtualenv
We need to create the space for our work. Its no more than a directory in your home, but you should treat it with some respect. Use it only for housing your code, and don't litter it with random files. I like to work at the top level of my home, so that's where I'm going to create
PythonDev
cd
mkdir PythonDev
cd PythonDev
Now we need to install the tools that will set up our development environment for us. We will need:
- pip - the python package installer
- virtualenv - the scripts for building virtual environments
- virtualenvwrapper - scripts that take the complexity out of working with virtual environments
You'll need admin rights for the next few steps
cd
sudo apt-get install python-pip
sudo pip install virtualenv virtualenvwrapper
That's it as far as getting the tools. We won't be needing admin rights for a while.
Now we set up virtualenv. First we need to give it the location of our working directory, as this is where it will store relevant files. It gets the location out of our
.bash_profile file. You may not have one, either way use nano to create it, or edit it if you have got one to hand. In the following code snippet, replace PythonDev with the full path to your preferred working directory.
You may need to edit the path to virtualenwrapper.sh script. If its not in /usr/local/bin, try /usr/bin
nano ~/.bash_profile
export WORKON_HOME="$HOME/PythonDev"
source /usr/local/bin/virtualenvwrapper.sh
Activate your wrapper script by sourcing your .bash_profile
source ~/.bash_profile
If all is going well you'll get some messages appearing about setting your virtualenv working space.
Now go wild. Create a virtual environment. I'm going to call my pydev.
mkvirtualenv pydev
Some more crazy messages follow, then hey presto, your new virtualenv is ready.
You'll know this because your prompt will have changed. Note the virtualenv name in parentheses before your regular prompt.
(pydev)ian@raspberrypi:~$
So now what can we do. We'll we've got a bunch of new commands to learn:
- workon <name of virtual environment e.g. pydev> # activates virtualenv
- deactivate # turns of virtualenv
- cdvirtualenv # change to virtualenv working directory
- mkvirtualenv <name> # create a new virtualenv of <name>
- rmvirtualenv <name> # delete virtualenv <name>
- lsvirtualenv # get a listing of virtualenvs
These half dozen commands cover the mainstay of operations, but as you may imagine there are a whole host more.
With our pydev env up and running, lets install an improved python interpretor
ipython. This interpretor boasts a whole host of useful features not present in the system default python. In ipython we can access shell commands from within the interpretor, as well as use readline to gain command history features etc.
pip install ipython
Note we don't need sudo anymore because we are working in our virtualenv
Step 2 - Version control
Right one more setup task for the day, and then its bedtime for me.
Lets install and configure a source version control system. What the ... why?
If we are going to write code, then we need to protect it from accidental damage. What better way to track our progress, secure our work and generally be truly professional about our business than checking it in. What's more, we can impress our friends when we pass them the URLs to check out our work.
We will use Subversion. Its a lot easier than you may image.
Back to admin.
sudo apt-get install subversion
Now we need a place to set up our repository - the fancy name for the home that will store our files. I suggest sticking SVN_Repo at the root of your home directory.
cd
svnadmin create SVN_Repo
We will set up ourselves as a user. We specify this in a config file. Use nano to enter the following text in ~/SVN_Repo/svnserve.conf
anon-access = none
nano ~/SVN_Repo/svnserve.conf
auth-access = write
password-db = passwd
Our user needs a password to be associated with it. Enter the authorization details in ~/SVN_Repo/conf/passwd. Its simply a file of user = password
nano ~/SVN_Repo/conf/passwd
ian = mypassword
So how do we know this is all working then?
Lets create a pyhthon project to test it out. The steps will be:
- workon pydev - activate our virtual environment
- cdvirtualenv and create the source directory
- make project subdirectory, move in and write script
- import the project in to our subversion repository
- blow the original project directory away
- checkout our project from the repo
- experiment with making and reverting changes
- go to bed with a sense of satisfaction
Testing out virtual env and subversion
I'm going to assume you called directories the same names as me, otherwise you'll need to change the recipe accordingly.
workon pydev
cdvirtualenv
mkdir src
cd src
mkdir my_test_project
cd my_test_project
nano hello_world.py
Type the follwoing hello_world.py listing in nano.
"""
Testing virtualenv and subversion
Hello World
"""
msg = 'Hello World'
for x in range(5):
print msg
# end
- Test your script by running it in ipython
(you can execute it directly or import it into the interpreter
ipython hello_world.py
or
ipython
import hello_world
exit
Both should yield satisfactory results (note when you import the file you miss off the .py). So lets check that bad boy in. In the following recipe we need to give the full path to our SVN_Repo, clearly substitute my username for your own!
cd .. # move back to src directory
ls # ensure you can see the directory containing our project - my_test_project
svn import file:///home/ian/SVN_Repo/my_project
Subversion asks for a message. Tradition has it that this message is always 'First commit', although you can call yours whatever you like. It may even fire up an editor that lets you type one in. Either way ensure you get a message across.
rm -rf my_test_project # Bye - bye unversioned inferior directory
svn co file:///home/ian/SVN_Repo/my_project # welcome back new and improved working directory now under version control
cd my_test_project # move inside project directory
svn status -v # get status pf files under version control
That's it as far as setting up version control. Clearly there is much to learn about how you work with files that are being tracked for changes. In fact you'll need to master a whole bunch of new command.
- svn add <name> # put a new file under version control
- svn rm <name> # delete a versioned file
- svn commit -m 'message to log in commit'
- svn up # Update the working copy with changes that have been commited
- svn status # get status of versioned files.
- svn revert #recover drop uncommited changes and revert to head
- svn co # check out a new working copy
- svn diff <name># find out what changes exist between your file and the repo's version of the file
- svn log # get a print out of the log entries accompanying commits
- svn blame
- svn merge -r downgrade / upgrade working copy revision x to / from y#
The general strategy goes like this.
- Create a new file in your favourite text editor. Enter some text etc.
- Add (some people call it staging) the file to version control. Note this doesn't physically commit the changes
- Commit the file together with some message describing your edits
Now when you make subsequent changes to these files, you'll need to commit any edits. Its important to remember not to simply rm a file under version control, you need to tell subversion that you no longer want the file to be tracked. Do that with
svn rm.
Testing out.
Move back into our project and edit the file in
nano. Lets change the
msg variable to something else.
"""
Testing virtualenv and subversion
Hello World
"""
msg = 'Goodbye World'
for x in range(5):
print msg
# end
Ok so its not a radical edit, but it is a change. We can know that the file is modified from that which is in the repo (known as the head copy) with svn status
svn status
M hello_world.py
We can also review the changes using svn diff. This literally creates a diff file that would patch the head, making it the same as the working copy.
svn diff hello.py
Index: hello.py
===================================================================
--- hello.py (revision 6)
+++ hello.py (working copy)
@@ -2,7 +2,7 @@
Testing virtualenv and subversion
"""
-msg = "Hello World!"
+msg = "Goodby World!"
for f in range(5):
print msg
The values between @@s give us the code for where the changes are. It says delete (-) offset two lines below @@ (at line 7 in file this is Hello) and replace (+) with Goodby. Effectively swap the print msg statements.
So we commit the change
svn commit -m 'Edited message'
Hit enter and realise we've made a terrible mistake. Don't Panic. The file is under version control. We can check the logs to find out what revision we need to recover, then pull it back. Before we can do the reverting we need to update our local cache (working copy) with any changes that we (and anyone else) working on the project may have checked in, we use
svn up for this purpose.
svn up
Now we can check the logs and find out what version number we need to revert to.
------------------------------------------------------------------------
r2 | ian | 2012-07-02 23:40:46 +0100 (Mon, 02 Jul 2012) | 1 line
Edited message
------------------------------------------------------------------------
r1 | ian | 2012-07-02 23:36:35 +0100 (Mon, 02 Jul 2012) | 2 lines
First commit
------------------------------------------------------------------------
Well we've only made one commit above first commit, so lets go back to r1.
svn merge -r 2:1 hello_world.py
You can now commit downgraded hello_world, and it will take the next revision number in the change r3 in this case. The important thing to understand is that the diffs that made up the journey are still in the repo, and its possible to walk backwards and forwards through them. That's the beauty of version control
Next time I want to skirt through Project Management.
