protoc-gen-mypy: program not found or is not executable

Summary

make all-devel failed with protoc-gen-mypy: program not found or is not executable

Steps to reproduce

make all-devel

Expected behavior:

It should build out successfully.

Actual behavior:

protoc-gen-mypy: program not found or is not executable Please specify a program using absolute path or make sure the program is available in your PATH system variable --mypy_out: protoc-gen-mypy: Plugin failed with status code 1.

Is this a regression?

That is, did this use to work the way you expected in the past? yes / no

Debug info

• Streamlit version: (Streamlit, version 0.47.4)
• Python version: (Python 3.7.3)
• Using PipEnv
• OS version: Mac OSX 10.15.2
• Browser version:

Additional information

Latest streamlit commit @ 26c953641d5f91a1d59bf1cef205179105d4c6e3

Looks like it’s since this commit: https://github.com/streamlit/streamlit/pull/1079

[zhaoooyue]

fixable via pip install mypy-protobuf

[whiten]

Hi @1wpro2. Thanks for confirming the analysis of what went wrong. I understand that in your opinion we should retain the lock file. I think valid arguments can be made either way, and you should open a new bug if you want to articulate a clear reason why you think it should be retained that weighs the pros and cons.

In my opinion of that of the reviewers of that change, the value the lock file was providing was minor, and arguably negative. While it would ensure that an individual developer could consistently produce virtualenvs with the same dependency versions if the Pipfile hadn’t changed, the downside was that the world (i.e., the versions of those dependencies that other developer would receive) could be moving ahead, potentially with breaking changes, while the core Streamlit team was blissfully unaware.

I think this debate would be very different if we published a lockfile that was tested against, but we don’t, and we can’t really, because streamlit is used in environments with other libraries that we may share direct or indirect dependencies with.

The above mixed benefits and drawbacks, taken together with the lower latency of using pipenv with --skip-lock, led to the change we made.