[erlang-questions] Coon - new tool for building Erlang packages, dependency management and deploying Erlang services

zxq9@REDACTED zxq9@REDACTED
Mon Feb 12 18:28:47 CET 2018


On 2018年2月12日月曜日 12時10分20秒 JST Tom Santero wrote:
> Putting the project's name aside for a moment, there are two things I'd
> like to point about:

THANK YOU

> 1. i would never pull a pre-built binary from a 3rd party into one of my
> projects. lol security?

I disagree, in that we are right back in "trusting trust" territory. I prefer building from source (for a number of reasons) but source or not, for nearly everyone (perhaps actually everyone) who builds a project that involves external dependencies, the security is only as strong as the signature on the code received (and implicitly, the trust of the signature scheme employed) and the trust of the review process which granted the signature.

Both are greviously lacking in using direct-from-github packages (whether source or pre-built) as repository inputs.

> 2. that this project doesn't address rebar3/relx/hex at all means it is at
> odds with the direction the community has been pushing toward for several
> years now, and makes it relatively useless

I disagree again. In this era we have full-blown systems to drive; the common case today is NOT to deploy to a resource-strapped or custom-built piece of hardware that can never be accessed by system administrators. The common environment today is more like a (to use an awful term) "devops" environment where people want things to rebuild in the lightest possible way and "just go". Which is to say, people desperately wish that Erlang (not to mention Elixir) code could be more commonly built and run the way Python projects that use virtualenv can be.

I think the to-date direction of the Erlang community de facto practices is a bit dated, being built around the ancient and original assumption "everything has to be an Erlang distribution".

-Craig



More information about the erlang-questions mailing list