agable@ mentioned that there is plan to migrate from DEPS to git modules. If that happens, it would be great if we could have backward compatibility.


cc other app owners on this bug.

Yep, this is definitely something that we want to provide. We already *almost* provide it: use-cases which have access to a subprocess environment can run "gclient flatten".

But yes, better would be to have a library which consumes DEPS files (including over the network, pulling contents from googlesource) and produces a dependency tree.

How upset would people be if it were in Go, since we try not to write any new code in Python? (I know, doing it in Go is a long shot anyway, since DEPS files are literally python, but I'd like to discuss it anyway.)

From what I know, the apps I mentioned above are all in python. So a python library would be appreciated!

Put differently, a Go library would be worse than a command-line interface :).

Any updates for this bug? 

recently the DEPS parser for Findit and Predator failed to parse the buildspec DEPS, I can do a hacky fix but think it might be much cleaner that we can have a such a shared and well-maintained lib to parse DEPS file. 

DEPS files are now parsed via gclient_eval.py, a stand-alone DPES-file-parser in depot_tools. However:
1) it isn't executable, it's just a library.
2) it's in depot_tools, so importing it from elsewhere is non-trivial.
3) we don't guarantee that its API is stable yet.

We, the chrome crash team, has a job that exports blame/source info to our frontend http://crash, and our job depends on parsing DEPS file. Our code is in C++ but we could use a python parser.