Hi @nathanhammond. Thank you for your interest in the library. Sure, that would be great.

I assume the PR would add an interface which defines all permitted file system operations and a 'local fs' implementation of that interface, which would be the default?

If that's the implementation that you feel like makes the most sense, then, yes!

I'll get you a draft PR for your consideration up shortly.

Sorry, I was just wondering if you were thinking of something along those lines 😄.
I'm not sure if it's the best way to do it, just my initial thoughts on this.

@nathanhammond are you working on it? Because I'm also interested in it hehe.

I was mulling over porting an internal tool's config system to use more standard directories over an upcoming lull and might be able to pick this up if wanted by @adrg .

Off-topic Background
For my own usage/needs, I need something equivalent to fs.Glob
or fs.WalkDir, to replicate a behavior where end-user config files
are merged with system provided files
(e.g. defaults.yml,user_config.yml, local_creds.yml)

I've done relatively little research thus far, but noticed that the open pull
request used afero. If possible, I'll attempt to use io/fs in my design since that's now definitely stable.

Seeking input on some possibilities (very rough sketch):

• var values whose value or values implement io/fs.FS
  • declared like var DataHomeFS fs.FS to maintain backward compat
  • at its simplest set as os.DirFS(DataHome)
  • facilitates mocking/fallback injection
• var values that themselves implement io/fs.FS
  • enabling an interface like fs.Glob(xdg.DataDirsFS,"appname/*.sh")

Uncertain how much performance penalty the added indirection would cause, and so feels like unit/performance tests are warranted. Just wanted to get your thoughts before spending addl time evaluating it next month.