URIs produced by pytroll-watches not understood by trollflow2/satpy

[gerritholl]

When watching a local filesystem, pytroll-watches produces file URIs. Passing those to trollflow2 will lead to a failure in reading the file by satpy:

[2024-12-06 13:03:36,461 INFO     trollflow2.launcher] New message received.
[2024-12-06 13:03:37,805 INFO     trollflow2.plugins] Creating scene
[2024-12-06 13:03:37,948 ERROR    satpy.readers.netcdf_utils] Failed reading file file:///data/pytroll/IN/FCI_FDHSI/W_XX-EUMETSAT-Darmstadt,IMG+SAT,MTI1+FCI-1C-RRAD-FDHSI-FD--CHK-BODY--DIS-NC4E_C_EUMT_20241206130057_IDPFI_OPE_20241206125849_20241206125914_N_JLS_O_0078_0038.nc. Possibly corrupted file

To resolve this, either:

• pytroll-watches would need to publish messages with a direct path, without the file:// scheme, or
• trollflow2 would need to strip off the file:// scheme, or
• satpy would need to understand how to read file:// URIs.

The first option would have the advantage that it would be backward compatible with trollstalker. There may be other packages trying to access files, such as runners, movers, or log analysis tools. The second and third alternative would have the advantage of consistency between local and non-local files.

[gerritholl]

I just learned that the segment-gatherer apparently has an option to strip off the scheme:

all_files_are_local

Optional. If set to True (defaults to False), segment gatherer will handle all files as locally accessible. That is, it will drop the transport protocol/scheme and host name from the URI of the incoming messages. The use case is for protocols that fsspec do not recognize and can’t handle, such as scp://.

That would solve the pytroll-watches limitation for those cases where a segment-gatherer is used (in principle it could be used even when there is only one segment, just for stripping off the scheme, but that seems a bit of a misuse of the segment gatherer).