David Pordomingo

I'd say that [my other answer](https://github.com/src-d/sourced-ce/issues/109) fits here.

@marcelo asked about how to connect with Jupyter, so I assume it can be a legit use case. But yes, we can also consider if there is any counterpart in...

Also, if use cases like the requested by https://github.com/src-d/sourced-ce/issues/170 are legit, it seems that running `sourced` without accessing the web interface could be also considered as a nice to have.

Nope. The requirement was about to use named env vars to signify the constraints between the same data in different containers, e.g. to use `${METADATA_DB_NAME-metadata}` instead of the same hardcoded...

About being possible, I'd say yes; I'd maybe change "org" by "owner", being able to be either a "user" or an "org"; doing so we would also avoid problems if...

I wouldn't do it automatically but maybe with options: `--use-parent`, to use the parent repo instead, or `--add-parent` to fetch both: original, and parent; or even fully ignore forks with...

That would be nice. imo we should have a design doc to consider which exit codes do we want, and maybe to regularize error message.

why can't we check if one of the aliases of the required language is one of the exposed by `bblfsh`? I mean: - source{d} Engine use `enry` to guess the...

Sorry, I missed something... I don't see why is it a problem on `bblfsh`... I ran `bblfsh` container with images: ```shell $ docker run --rm -d --name bblfshd --privileged -p...

So my question is: Does the [filter](https://github.com/src-d/engine/blob/master/cmd/srcd/cmd/parse.go#L99) makes sense in source{d} Engine? - If we want to avoid sending files to `bblfsh` if we already know that there is no...