fix: match os.PathLike too

[henryiii]

Starting in Python 3.8 (and older versions on UNIX), subprocess accepts os.PathLike arguments. This adds support for that in fp.register too.

Closes #101.

[aklajnert]

This needs a test, with the real subprocess usage by calling the example_script.py - see test_basic_process for an example. It will help to ensure that the mock behaves exactly the same as the subprocess. I think it will require also adding a check for the python version to behave appropriately on python < 3.8.

[henryiii]

Python 3.6/3.7 should happen to work too, as long as it’s not Windows. I’ll try to add this soon.

[codecov-commenter]

Codecov Report

Merging #109 (2bf339b) into master (e7c9e4c) will not change coverage.
The diff coverage is n/a.

❗ Current head 2bf339b differs from pull request most recent head bb9bab7. Consider uploading reports for the commit bb9bab7 to get more accurate results

@@      Coverage Diff      @@
##   master   #109   +/-   ##
=============================
=============================

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[aklajnert]

Instead of skipping it on Windows for 3.7, I'd rather prefer to behave similarly to the real subprocess on this platform. I see it raises TypeError there, so I think this plugin should recreate this behavior to be reliable.

[henryiii]

Okay, I've changed the tests to verify exactly what happens, rather than skipping. I think what you are asking is you'd like the not fake condition above to be removed? That's a bit of a follow up (a feature that touches some of the same code, but is an independent improvement). This improvement specifically makes Path("x") match "x", while before they only matched if you called the subprocess with the exact same object as the registration set. Having Path("x") throw the same error as the real subprocess on Win < 3.8 seems like another good addition. I can do that here or in a followup. (PS: going on vacation tomorrow, so might not be doing too much this week).

[aklajnert]

Yes, that's what I meant. There is no rush with this (unless you do need it fast?), so we can wait for you to come back from vacation or we can merge it as is now and work on this TypeError later (I could also work on it if you prefer). Let me know what you prefer, I'm OK with both.
And have a nice vacation :)

[henryiii]

Minor preference to merge this, then work on TypeError, since it's a distinct feature (that happens to modify this test).

I'll see if I can work on it in the next couple of hours, otherwise it will likely wait or be something you work on. :)

Unless you are in a rush to release something, I'd like to test this out with scikit-build-core pulling the plugin from git once everything is in to see how the recents fixes works in a project.

[aklajnert]

I'm not in a rush at all, I can wait for a notification from your side that all is OK and I should release a new version.