assert(&Path) doesn't compile

[SoniEx2]

https://docs.rs/assert_fs/1.0.1/assert_fs/assert/trait.PathAssert.html#required-methods says you can pass a &Path, but this errors with:

error[E0277]: the trait bound `&Path: IntoPathPredicate<_>` is not satisfied
  --> src/git/tests.rs:54:36
   |
54 |         clone.child("HEAD").assert(repo.child("HEAD").path());
   |                                    ^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `IntoPathPredicate<_>` is not implemented for `&Path`

[epage]

I agree this would be convenient for validating against a "golden" file.

In predicates, this is exposed as a eq_file function, which will compare bytes. To compare a str, you do eq_file(path).str(). This doesn't address what if the user passed in (and intended) for directory comparisons.

With IntoPathPredicate, we can only choose one option, which do we go with? Whats the chance someone will be unhappily surprised and what will be the impact of that?

iirc one of the other concerns I previously had was the fact that we also support IntoPathPredicate for data (str, &[u8]). A str can be either the golden state or a path to the golden state, making the choice ambiguous, so I went all in on one to avoid using both and people assuming and being surprised by what a str might resolve to.

To be clear, none of this is to say "no", just sharing my thoughts in trying to weigh this out to see what other thoughts there are.

[SoniEx2]

Oh yeah hm... those are good points...

[jwodder]

@epage I think the main problem here is less that "assert(&Path) doesn't work" and more that "The docs say it works but it doesn't." If you don't want to support assert(&Path) due to ambiguous interpretations, then the line in the docs about PathAssert accepting &Path should be removed.

[epage]

That reference in the docs has been removed.