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

Already on GitHub? Sign in to your account

Unix.walk or equivalent #490

Open
c-cube opened this Issue Jan 2, 2014 · 8 comments

Comments

Projects
None yet
4 participants
Member

c-cube commented Jan 2, 2014

I'm not sure whether it exists already, but an equivalent of python's os.walk would be very interesting for scripting in OCaml. I could implement it maintainers think it's useful.

Owner

gasche commented Jan 3, 2014

Why not; there is an interesting, non-trivial logic to avoid looping endlessly in case of cyclic symbolic links. I'm not sure whether we'd want to return a sequence of directories, as Python's function does, or rather a tree (which can easily be turned into a sequence afterwards) -- I'd go for the tree interface.

Member

c-cube commented Jan 3, 2014

that's an interesting idea; it could even be a kind of lazy tree (similar to BatSeq) for early termination. I like it.

Owner

gasche commented Jan 3, 2014

OCamlbuild has a directory-walking implementation, which is amusingly named "slurp". Do have a look at slurp.{ml,mli}. Couldn't we just reuse this implementation?

Contributor

hcarty commented Jan 3, 2014

This looks similar to/could be built rather simply on top of the find function in FileUtils. How much overlap do we want between these libraries? Should something be used from there?

Member

c-cube commented Jan 3, 2014

Indeed, it even looks more powerful thanks to the test system! Maybe a batteries-friendly interface to FileUtils would be nice, then. Something like wrapping FileUtil.find in an Enum?

Actually that's an interesting global design issue: should we make wrappers around other libraries (lwt for instance?) with optional modules, that keep batteries quite small and still integrate it nicely with the rest of the OCaml ecosystem? Opam's conditional compilation would help keeping this sane.

Contributor

hcarty commented Jan 3, 2014

This may be getting off-topic for a github bug discussion - but what is the proper approach for wrapping an external library for Batteries-friendly use? There are a few which would be nice to have in a Batteries-friendly form (Calendar, FileUtils, Lwt).

Member

c-cube commented Jan 3, 2014

@hcarty let's move it to the mailing list if you want.
edit: done

Member

UnixJunkie commented Nov 6, 2015

I also need this sometimes.
There is one in FileUtils however.
Not sure we should have one in batteries too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment