Bug: 2 install_hooks bugs

[kbolashev]

Bug 1: Paths with ~ in them not getting expanded to the user home.

Example:

install_hooks(...)
with open("~/some/file.txt") as f:
    print(f.read())

The tilde wasn't being expanded and the wrong path was being read as a result (it was reading $CWD/~/some/file.txt)

Bug 2: Recursive call in DagsHubFilesystem.listdir() for passthrough paths:

If accessing a passthrough directory inside a mounted fs (e.g. something with site-packages), the listdir of the fs kept calling itself instead of passing through to the OS filesystem.
Example:

install_hooks(..., project_root=".")
print(os.listdir("./venv/site-packages"))

[dagshub]

Join the discussion on DagsHub!

[guysmoilov]

1. You intentionally don't expand the orig_path before passing it into the DagshubPath? Just so I understand why. Maybe a comment explaining it?
2. I think you introduced a bug here. The default open doesn't expanduser on the supplied path, from what I can gather. But now, with this change, every call to open will pass through us and get parsed here and then you use the returned absolute path in the call to __open. So I think instead, to be really safe, you should make sure to always call the underlying patched functions with exactly the same args as you were called with, making sure they're not modified in any way

[guysmoilov]

I guess comment 2 is also relevant for __chdir and __listdir etc.

[kbolashev]

[duplicating in-person chat]

You intentionally don't expand the orig_path before passing it into the DagshubPath? Just so I understand why. Maybe a comment explaining it?

Yes, this is because this original path is later reused in functions that have different behavior depending on the accessed paths (notable example: listdir, that returns different paths depending on whether passed an absolute or relative path)

Yea, you're right, I actually shouldn't be expanding it at all probably.

[kbolashev]

Added explaining comment to each of the field of DagsHubPath and how it's being used

[kbolashev]

Reverted the fix for "bug" 1, because after discussion we realised that it might just be a bug of the calling library that it's trying to access ~/... paths, since regular open also doesn't expand them