insomnihack

When sleep eludes, the keyboard beckons

git init

Leave a Comment

After a bit of trial and error, I’ve managed to get git running on my Windows box under Cygwin, on my Macbook Pro using the latest MacPorts, and on a remote repository located on NearlyFreeSpeech.net. I’m pretty much a git newb, so what follows may only be interesting to other git newbies.

I was able to get Bash completion working with git by using the instructions I found here. Bash completion is really nice, especially when typing out branch names.

I’m not currently using any GUIs (although I downloaded GitX on my Mac to look at branches), preferring to immerse myself in the command line in hopes of increasing my understanding of how git works. So far, the experience has been pretty positive. I’m still just doing basic stuff, and my only branch usage has been to create one-off development branches to hack out a feature. I’ve been deleting them after I merge back to master.

I have ran into a few issues. Moves aren’t has carefree was I was led to believe. Simple moves without file modifications are pretty transparent to git, but it doesn’t like it when you move and significantly edit a file. Instead of a nice rename in git status like this:

[text highlight=”6″]
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>…" to unstage)
#
#       renamed:    bar.py -> foo/bar.py
#
[/text]

You get something more frustrating, like this:

[text highlight=”6,12″]
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>…" to unstage)
#
#       new file:   foo/bar.py
#
# Changed but not updated:
#   (use "git add/rm <file>…" to update what will be committed)
#   (use "git checkout — <file>…" to discard changes in working directory)
#
#       deleted:    bar.py
#
[/text]

This is a bit of a drag. When refactoring, I don’t think of where I’m going to move files first, then edit them. Its all one flow. With subversion, I could always go to the repository and specifically tell svn that a new file and an missing file are the same. With git, I ended up archiving my changes, restoring my working folder, committing the moves, then copying the updated files from my archive. It may take awhile for me to start thinking in terms of move, edit, then commit in order to avoid this kind of problem.

I ran into a odd issue with test file permissions getting set to executable. I suspect the issue is related to git on Cygwin. Cygwin on an NTFS drive apparently assumes the file mode of new files is +x. I’ve temporarily worked around the issue by configuring git on Cygwin to ignore file modes.

[text]
git config core.filemode false
[/text]

Nose – Fix nosetests finding 0 tests

2 Comments

I ran into an odd problem with nosetests not finding my unit test files after a git pull. After a little googling, I found someone who’d had similar issues with the permissions of their test files getting changed. For whatever reason (perhaps pushing from Cygwin on a Windows box?), my git pull had set the execution bit on my test files.

Typically, nosetests ignores executable files unless you pass it the --exe command line option. For now, I ran a chmod -x path/to/test.py to make the file non-executable again. I’m going to have to keep an eye on this to see if it reoccurs.

Python Unit Test Location and Nose

2 Comments

Honestly? I’ve spent a ridiculous amount of time trying to figure out where to put my python unit test files. Sure, they worked fine located in the same directory as my source. However, the Felix Unger in me recoiled at the thought of my test files intermingling unsupervised with my main package source code. I’m pretty sure that’s how the Neanderthal went out.

After playing with __name__, relative imports, a half dozen folder configurations, IPython config tweaks, and in general just pulling my hair out at the roots as I chased the rabbit deeper into its hole, I decided to step back and revisit a tool I’d been meaning to check out for a long time: nose.

Sweet Judas Priest, the hours I could have saved! If you’re unfamiliar with nose, it extends the test loading and running features of unittest, making it easier to write, find and run tests. Its pure, buttery, test-running goodness.

What follows may be a bit basic for most experienced Pythonistas. For the rest of you Python noobs out there like me, here’s how I’m setting my packages and tests up now.

[text]
/MyPackage
/mypackage
__init__.py
spam.py
eggs.py
/tests
__init__.py
spam_tests.py
eggs_tests.py
[/text]

The source for my package goes under /mypackage. The __init__.py there contains the usual kind of stuff.

[python]
__all__ = [‘spam’, ‘eggs’]
[/python]

The unit tests for /mypackage go in /mypackage/tests. The __init__.py file in my /tests folder is empty. Since I’ve pretty much settled on nose, I’m not performing any additional test running tricks. Were I to add imports for my tests classes here similar to what I did in /mypackage/__init__.py, nose would run all my unit tests twice.

In my unit test files, I use relative imports to get at my source files. Relative paths only work within packages, so remember that the __init__.py files are required to make Python treat the directories as containing packages. For example, spam_tests.py would contain the following.

[python]
import unittest
from ..spam import Spam

class SpamTests(unittest.TestCase):
"""Unit tests for the Spam class."""

def testDefaultInitialization(self):
"""Verify the default values of a new Spam instance."""
s = Spam()
self.assertEqual(s.goteggs, False, ‘Spam already had eggs!’)

# etc…
[/python]

I don’t bother with adding if __name__ == '__main__' to the bottom of my test scripts in order to call unittest.main(). Setting the __name__ to '__main__' breaks relative imports.

Once I’ve got this basic layout configured, I’m ready to write my tests, implement the functionality in my classes, and verify everything works by running nosetests from my /tests directory.