Maybe replace filename-handling with universal-pathlib?

[jpivarski]

Just something to consider because it would change a lot of code (this would be a big task), but Uproot has some hairy filename parsing because

1. it handles local paths, including Windows drive letters, and URLs in the same string field
2. it handles external paths/URLs and inside-the-ROOT-file paths with that same string field, separated by a colon (and colons are necessary for Windows drive letters, URL schemes, and URL port numbers).

At least item 1 could be solved by universal-pathlib (import upath), which unifies local path and URL parsing. It might even help with item 2 because you can search for the colon separator after the global parts of the path (Windows drive letter, URL scheme, URL port) have already been identified and separated from the nested filename.

Something to be cautious of with universal-pathlib: it's not the only Python library that gets imported as upath. I don't know what would happen if both of them are installed in the same environment. (They have different PyPI names, but the same import name.)

[ikrommyd]

If uproot is to use upath, we'd need upath to support xrootd paths right or am I missing the point here? I'm asking because I relatively recently opened this fsspec/universal_pathlib#428 but haven't had time yet to implement the feature.

[jpivarski]

I see you're already on it!

I don't know if a URL scheme has to be built into universal-pathlib for it to be usable. I did see that they provide a list of schemes that they support. Pathlib has path-parsing functions and functions that do things on the file system or cloud storage (open files, make directories, etc.). The path-parsing functions only need to know the text of the URL scheme, "root", but the others would have to hook into XRootD and maybe also Uproot (for open). I wonder if they have a concept of tier 1 support (just parsing the pathname) versus tier 2 support (all the functionality).

Anyway, I opened the issue to tell you about the library, since I just found out about it and it would be a clean solution to currently ugly code.

[ikrommyd]

Yeah I had a case where handling path objects would have looked better than handling strings but gave up on it since I'd need a special string handling code path for xrootd paths 🤣

Anyways, I don't know much about the uproot code base (I just get notifications) so if the maintainers proceed with this feature you suggested, we can potentially also contribute the xrootd support to upath in the process.