The way the os module seems to reference posix, I don't believe we will run into any platform dependencies.  Since os determines what environment it is in then references either itself or an appropriate external module (such as posix) in __dict__, it should always work.

With os.readlink, the issue was that inspect.getmodule(target) was returning 'posix', so posix.__dict__ was updated when os.readlink was mocked.  os.__dict__, however, was not updated, so calling os.readlink() resulted in posix.readlink() rather than our mocked function.

If this doesn't seem correct, I would appreciate your feedback.

As for merging torproject/master into our branches, I'm afraid I don't know how that happened.  Should I revert to before that commit and rebase, or was this a one-time issue that we simply need to avoid in the future?

Best,
Erik & Megan

On Tue, Jun 19, 2012 at 3:25 PM, Damian Johnson <atagar@torproject.org> wrote:
Hi Eric.

> First, to clarify our github repository situation...

gotcha

> Next, in continuing work on the unit tests for proc.py, we ran into another issue with the mocking code.

Nice catch, though for your example (os.readlink) won't this make the
tests platform dependent? Currently Beck (another volunteer working on
stem) is working on making the tests run on Windows and it would be
sad if we made his life harder. ;)

Minor gity side note, there is almost no use case where you should be
merging 'remotes/torproject/master' into your branch. Either rebase
onto 'remotes/torproject/master' or make a new branch on
'remotes/torproject/master' instead. That will make your dag (directed
acyclic graph - the parent/child relationships between commits) far
cleaner. Otherwise I need to cherry-pick rather than merge your work
since merging would pull extra commits and confuse the master's dag.
Let me know if you have any questions about this - admittedly without
a whiteboard git can be a little confusing for new users.

Cheers! -Damian