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.orgwrote:
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