Understanding provider.Walk

[mcorossigo]

Hello @mouuff

I'm planning on writing a new provider for my own use case, and I'm trying to get the the mindset right.
Can you explain the reasoning behind the Walk function?

From my initial study it appears to always fallback to the local provider walk.

Also, I'm not really getting why you decoupled Walk and Retrieve.
I feel like merging those (like retrieve on walk) could make sense in scenarios like #16

Just ideas to better understand the intended flow.

Anyway,
Thank you.

[mouuff]

Hello,
Thank you for your interest in this project!

Can you explain the reasoning behind the Walk function?
The walk method provides a way to iterate the files that can be retrieved from the provider.
To call the walk method you must pass a func(info *FileInfo) error which will be called for each file, giving information about each file.
(Currently just path and mode)
FYI the path in FileInfo is relative to the provider, it is not a system path (for example: just /something.exe, then you can call retrieve on /something.exe if you want)

it appears to always fallback to the local provider walk
You are right, very often we just call the local provider. This is because most providers at the moment just download an archive with all files and then files are on the local drive.
However, this doesn't need to be like that for all providers. You can implement a provider that would just download the file that the program needs.

Also, I'm not really getting why you decoupled Walk and Retrieve:
I made it like that because it is more flexible. I don't want to be stuck with a design that forces you to retrieve all the files just to know what is there / if it is there.
This also allows you to retrieve "special files" for example if you want to make a feature and get some metadata from your provider, you could provide a file for that. (For example a certificate file from your server, or anything you can imagine)