Not possible to escape colon in filenames / avoid object-in-file path syntax (?)

[ryuwd]

This is of course something of an edge-case with EOS tokens, which contain colons :. This means xrootd paths can have a format which may confuse uproot4, which looks for an object-in-file path by default:

https://github.com/scikit-hep/uproot4/blob/3fe33aff6d6ed88203eed90f4edb5f2bc720f3e6/src/uproot/_util.py#L241

This means when using uproot.open('root://some_xrootd_path//eos/mount?authx=token:with_colon'), the token (needed for the authentication) will be cut short.

Can we switch off the object-in-file path parsing, or workaround it somehow?

Version 4.1.9

[jpivarski]

You can use pathlib.Path objects, which asserts that this must be a file path, no colon funny business, or you can use this syntax:

uproot.open({"root://some_xrootd_path//eos/mount?authx=token:with_colon": ""})  # left and right of colon as a dict

The last time this was asked was #365, and the first time, which generated a long discussion about what we should do, was #79. As soon as I saw the corner cases, I thought it would be good to remove the feature entirely (convenience for most people shouldn't make things aggravating for some), but the ensuing discussion convinced me that there are cases in which the colon is necessary, such as selecting a lot of files with a wildcard. (The dict syntax also allows for that, too, but it is non-obvious. The file-not-found error message suggests it, and it's in the uproot.open documentation, but that still doesn't qualify as "easy to find.")

[ryuwd]

FYI: the {xrootd_url: ""} workaround no longer works - uproot will insist on a non-empty tree name

using Path(xrootd_url) unfortunately results in FileNotFoundError: file not found ([FATAL] Invalid address) as pathlib.Path mangles it

uproot 4.3.7

[ryuwd]

Apologies for digging up this old discussion!

[jpivarski]

What about {xrootd_url: None}? I was reminded in a recent email that {xrootd_url: ""} looks for an object in the file named "".

(For history, this colon-parsing was a community decision, but a contentious one (#79).)