Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disjointed ways of finding files #13

Open
epage opened this issue Feb 11, 2018 · 3 comments
Open

Disjointed ways of finding files #13

epage opened this issue Feb 11, 2018 · 3 comments

Comments

@epage
Copy link

epage commented Feb 11, 2018

(Originally on reddit)

In looking at the holistic API

  • Glob and walkdir feel like appendages to the API rather than
  • Glob and walkdir fill similar purposes
  • Glob feels stringly typed. I'd assume it'd be a function on a path type that then takes in a string
  • walkdir doesn't integrate with the path types
@epage
Copy link
Author

epage commented Feb 11, 2018

One concern raised on reddit for wrapping walkdir is the very nature of wrapping it. For a higher-level, ergonomic API, do we need to expose the full power of the API? I feel like we can assume the users of the library are already sacrificing performance for ergonomics. walkdir on the other hand was heavily designed for performance. This provides a way for alternatively exposing walkdir in a simple way that integrates with the rest of the crate.

@vitiral
Copy link
Collaborator

vitiral commented Feb 11, 2018

Glob and walkdir feel like appendages to the API rather than

I think you didn't complete this sentance 😃

Glob and walkdir fill similar purposes

I agree with this to an extent. The main reason that glob exists is because we are targeting the CLI space and globs are ubiquitous for CLIs. That's also why we have shellexpand.

For a higher-level, ergonomic API, do we need to expose the full power of the [walkdir] API?

I actually hadn't considered this. In some ways the only APIs we need are:

  • simple iterator
  • ... with the skip_current method on the iterator.

This is really all I have needed for some pretty complex applications. Sorting the output, breadth-first, etc are not often needed features and while the filter function theoretically improves ergonomics I've found it actually quite difficult to use effectively (quite often you depend on outside state and it ends up being annoying to handle the lifetimes correctly).

@epage
Copy link
Author

epage commented Feb 12, 2018

Starting from requirements, which you just gave, I think will be important for this. I think another good angle is "what do other high level APIs do" (Python's pathlib being the one I'm most familiar with but they intentionally left functionality off of it like walk and shutil).

I think what you listed works well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants