Closed blt closed 11 years ago
Hmm, travis-ci timed out building the app.plt. Probably best not to include dialyzer if the damn thing can't spec check a project this small in 10 minutes.
I like making the repl depend on compile. (If we add sync support, we would never have to exit.) But I don't think dialyzer should be part of the test suite. We can tell travis to run it by adding a custom build lifecycle command, but for day-to-day development, dialyzer's cost is high enough that I don't think it should be part of test. It is ~2.5x slower than the tests on my laptop, and needing to generate the app.plt file degrades the "unboxing experience" for new developers at the moment their enthusiasm is highest (and before they have made any changes which could introduce problems a PLT file is required to detect). I suspect, however, that we have different views of how dialyzer fits into Erlang development in general and in the particulars, so there is a larger conversation to be had.
I like making the repl depend on compile. (If we add sync support, we would never have to exit.)
That's a PR I'd +1.
But I don't think dialyzer should be part of the test suite. We can tell travis to run it by adding a custom build lifecycle command, but for day-to-day development,
Didn't know about the custom build lifecycle command.
dialyzer's cost is high enough that I don't think it should be part of test.
Begrudgingly agreed.
I suspect, however, that we have different views of how dialyzer fits into Erlang development in general and in the particulars, so there is a larger conversation to be had.
Likely--and we should have that conversation--but the practical reality of dialyzer makes the assertion that types are as equally important as tests moot.
The last point, I think, will be the most important. When it's not run by travis-ci it's entirely possible that the working developer will forget to run the validate target.
I know I do.
Signed-off-by: Brian L. Troutwine brian@troutwine.us