Fix name of mock test method

[gtback]

assert_has_call is not an assertion method on Mock() instances, so none
of these tests had a chance of failing.

I discovered this while attempting to add a test for #210. An alternative would be to switch to using assert_any_call.

[bitprophet]

Ugh, the problem with "any attribute is cool on a mock". Thanks for catching this.

I think the actual correct replacement is assert_called_with, no? (That lets you just slap in actual args, not a call, which was the original intent in these tests.)

[gtback]

I'm not sure that assert_called_with works; at least, it didn't when I tried it (but I'm not an expert Mocker at all). From what I can tell, assert_called_with only checks the most recent call, but load_yaml gets called several times (for the system config file, the project config file, the user config file, etc.) . assert_any_call is a bit less restrictive, but seems to pass all the Linux tests.

Expected call: _load_yaml('/etc/invoke.yaml')
Actual call: _load_yaml('/Users/gback/.invoke.yaml')

In this case, by looking at load_yaml.call_args_list, I see call('/etc/invoke.yaml') in the call list; it just isn't last.

The Windows tests are still failing and I'm not sure the best way to generalize them (particularly for the user and system tests).

[gtback]

But yes, having the assert contain just args rather than call() instances would be better. 😉

[bitprophet]

Ah yea, you're right, the intent was "any call" not "first call", and assert_any_call should do that. Let's go with assert_any_call then. YAY BIKESHEDDING

[gtback]

I finally got a Windows environment set up where I can test this locally. The two tests that seem to be failing are:

• config.init.default_system_prefix_is_etc
• config.init.configure_project_location

You've already mentioned that the "system prefix" doesn't make much sense on Windows. Also here. Would it make sense for the "system-level" config file to just be C:\invoke.(yaml|json|py)?

The "project_location" test seems to just be a hard-coded path separator ("/") that doesn't translate on Windows. Easy fix.

[gtback]

The Windows tests on AppVeyor seem to be passing (crosses fingers), but Travis seems to be getting errors building virtualenvs. I don't think that's related to this code. Perhaps manually restart the Travis build?

[bitprophet]

Hm nope that's my fuckup, I started experimenting with code coverage and probably forgot to flip some bits somewhere. EDIT: found it, it's Travis-specific which is why I missed it. Pushed fix, will hit rerun on your build in a bit. Thanks!

[bitprophet]

Er right, we can't actually rerun THAT build as it's SHA pinned. If you merge master I think it'll automatically kick off a new build.

[bitprophet]

Also, +1 on default being just C:\, though - isn't there some semi-global "system stuff" paths in Windows, some junk using % characters and such? IIRC the problem is just that those things change depending on Windows version - so it may still be more widely applicable to just use the system volume root after all.

[gtback]

Completely off the top of my head, so may be wrong:

There's %SYSTEMROOT%, which I think is typically C:\Windows\ ... but I don't think you want users dropping config files in there. It's more like /usr/bin than /etc (gross generalization).
In reality, we should probably use %SYSTEMDRIVE% rather than C:\, but I'll leave that choice to people who are actually planning to actively use invoke on Windows. 😄

I'll merge master to kick off a new travis build.

[gtback]

It looks like the coverage that is missing is actually a task in invocations.testing. I don't see it anywhere in the history of https://github.com/pyinvoke/invocations/commits/master/invocations/testing.py. Perhaps something you haven't pushed?

invoke/tasks.py

Line 5 in c9f1112

from invocations.testing import test, coverage as _coverage

invoke/tasks.py

Lines 91 to 94 in c9f1112

	# TODO: allow functools.partial objects to work as tasks? hrm
	@task
	def coverage(c):
	_coverage(c, package='invoke')

[gtback]

You should be able to "restart" a Travis Build if you're signed in. It's useful if the failure depends on something outside of the code (such as the wrong version of invocations getting pulled).

[bitprophet]

Ugh, yes, that task is local, sorry. The danger of having a bunch of interconnected pip install -e versions of things. Just pushed, will try to make travis rebuild after (which in this case, yea, would work; earlier, it was a change to dev-requirements in this repo, which did require a merge).

[bitprophet]

Gross, travis (distinct from my testing on workstations) is really mad about something in the newer pty related code (so, not your fault). I'll have to figure that out. EDIT: #253. that's my top priority for this project right now, so it'll get done sometime soon, hopefully this weekend. Traveling tonight.