Deprecate glob in favour of globset and globwalk?

[KodrAus]

The glob crate has some deficiencies that are addressed by globset, but it comes with its own set of trade-offs. The globwalk crate offers a glob function, based on globset, that's a missing piece of the globset API.

There's a willingness to deprecate glob in favour of globset and accept its trade-offs as facts of life that can be improved by the compiler.

We probably need someone to take up the cause and help push this forward.

[BurntSushi]

A possible path forward here (although, my personal bandwidth for this is super limited):

• Don't deprecate glob, but re-purpose it. The name is ideal. Instead, we might consider deprecating globset and moving its API wholesale into glob. Then we produce a new breaking glob release. This path is useful if we care about moving the ecosystem over. It's less useful if we don't care about that as much.
• My suspicion is that folks expect "globbing" and "glob the file system" to live very close together. It would be nice if they were in the same crate. I had some thoughts here previously. In particular, whatever the case, it should be possible to get "globbing" without the dependencies required for walking the file system.

I think a key issue here is that "glob the file system" needs to be proved out and polished.

At a higher level, it's also worth saying that globset (or glob, if we took that route) will live on and get maintenance support so long as ripgrep is alive, so I do think it makes sense to take advantage of that!

[KodrAus]

Thanks for your thoughts @BurntSushi!

Personally, I'm in favour of re-purposing the glob crate as globset's current API, and shifting libraries into places where they get greater than zero on-board maintainers is what this is all about! :)

I'm guessing we're not in a big hurry to do this, so could work towards proving and polishing the glob the filesystem case in globwalk before repurposing glob? The main point from @BurntSushi's list for me is the first one about nailing down a specification for how traversal should behave that gives us room to optimise the implementation. Maybe that's the next step here?

@Gilnaa Do you have any thoughts to share? I know it hasn't actually been very long since you started working on globwalk.

[Gilnaa]

I am not against breaking changes, per se, but removing file-system traversal from glob is a funny move, as it doesn't just change the API, but the purpose of the crate.

It might be a viable move once we prove globwalk's API is sufficient, but I am still a bit weary of it.

[KodrAus]

@Gilnaa I agree it would be a bit strange to do that. I'm assuming we'd effectively deprecate both globset and globwalk, by combining them in glob with a feature gate for directory traversal.

It would be good if we could get concrete about what proving globwalk's API sufficient means.

[Gilnaa]

Well, globset's API is a superset of glob's, so it's probably not that big of a deal; but if we could get some community feedback about it would be great.

[kinggoesgaming]

I am in favour of glob being repurposed and the other two crates being deprecated

[Dylan-DPC-zz]

Yeah I am in favour of having a single crate for both. We can use feature gates in case people would want only 1 of the 2 functionalities.

[BatmanAoD]

If glob were repurposed, and we maintained separate crates for just globbing (i.e. globset) and globbing the filesystem (globwalk), my vote would be to repurpose glob as a globwalk alternative (either based on globset + traversal, or simply based on the existing globwalk), and leave globset with its current name.