refactor: drop path.py

[henryiii]

Closes #583. Removes a deprecated dependency.

[henryiii]

I'm not likely to have time to power up a Windows machine to investigate why this is failing on Windows for a couple of days - in a workshop this week. If PATHEXT is off, then don't see why anything works, and if it's right, I don't see why this isn't finding things correctly. Maybe I've got a bug around py handling. 🤷

Also need to think about how to add a test for the "not found locally but found in the default path" branch for coverage, which is showing up on ubuntu except for 3.10. Which is odd.

[DiddiLeija]

Let me check the Windows thing around the next days 😉

[FollowTheProcess]

Thanks for tackling this @henryiii! I can answer the 3.10 coverage thing, it is flagging the same section of code as uncovered (see below)

But in the Noxfile we set the coverage fail threshold to 99% here:

nox/noxfile.py

Lines 71 to 76 in d947833

	# 3.10 produces different coverage results for some reason
	# see https://github.com/theacodes/nox/issues/478
	fail_under = 100
	py_version = sys.version_info
	if py_version.major == 3 and py_version.minor == 10:
	fail_under = 99

This is a hangup from when we started testing on 3.10.0-rc.2 and something about 3.10 made coverage incorrectly flag stuff as uncovered, looking at the coverage logs recently though I think we can remove this little flag (I'll do this later today).

Sadly that doesn't help us with the build failures on this PR, which I agree are a bit weird!

Also need to think about how to add a test for the "not found locally but found in the default path" branch for coverage, which is showing up on ubuntu except for 3.10. Which is odd.

Regarding this, I can't think of a scenario where this would the case? As in where would you have a program that you can't find locally but exists on $PATH? I'll have a think on how we could test for this. Great work so far though!

[henryiii]

I think such a scenario would be looking for something like git. It would not be available in the local paths that are being passed, but would be available in the system paths, so it would only be detected in the second run (AFAICT, if you give custom paths, the system paths are then not included).

[henryiii]

That's embarrassing. Just don't look in history and pretend I wrote it correctly the first time. :)

In my defense, I somehow thought the new-in-3.7 text=True parameter also implied capture_output, even though I also knew it was just an alias for universal_newlines=True. That would have been handy, I think...

Also I needed to boot up a Windows box for other things, though I do feel slightly ridiculous needed it to discover this.

I'd really have liked it if this was protected by type - if mypy could tell you couldn't access .stdout/stderr without capturing output in some way, for example!

[henryiii]

Hmm, so it looks like shutil.which expects executables to follow Window's PATHEXT and looks for .exe, .bat, and such. The tests make a no-extension executable, which shutil doesn't find but the py.path tooling did. I'll have to investigate a bit further to see what the best solution is - it's probably at most just needed in the commands.which function if a workaround is needed.

[henryiii]

Closing in favor of #647.