Suggestion: Application Inference Should not apply to :dev or :test only dependencies

51 views
Skip to first unread message

Jeremy Huffman

unread,
Dec 7, 2016, 9:13:41 PM12/7/16
to elixir-lang-core
Application Inference is a good idea, but its introduced some breakage in Dialyxir (https://github.com/jeremyjh/dialyxir/pull/57) because it tries to start :wx if Dialyxir is added as a dependency and apparently this fails for some people (I couldn't reproduce, but there is no reason :wx should fail to start on my system). It is unfortunate :wx is even a dependency, but it is a dependency of :dialyzer and there is nothing I can do about that. The only fix I'm aware is the one submitted, which updates the README.md to suggest disabling runtime on this dependency. This is unfortunate, because it means everyone will hit this and thrash a bit at some time. 

Off the top of my head, I can't really think of any :dev or :test only dependencies that people want/need started. Am I wrong about that? Could we give those a miss where inference is concerned?

Regards,

Jeremy

José Valim

unread,
Dec 8, 2016, 4:32:03 AM12/8/16
to elixir-l...@googlegroups.com
It seems you are having the opposite issue that all other applications had so far.

Our initial idea was to include only :prod dependencies but we ran into issues in cases like "what happens if a dependency is only listed in production but not in the current environment?". Then your app would fail to boot although now I realize we could change the rule to only include applications that "are in the current environment AND production".

However, it is also worth noticing that the current approach is convenient for development and test, because you no longer need to start dev and test-only applications manually. For example, imagine you always want to run development with a debugger, previously you would have to start it manually but the current approach handles it for you. This also applies to staging, imagine you have certain tools you want to run on staging but not in production. The current approach makes it work transparently.

On the other hand, the current approach makes it so each environment has a different set of applications list and that's something that may be confusing.

I will discuss this with the team and see on which side of the trade-offs we want to sit on.


José Valim
Skype: jv.ptec
Founder and Director of R&D

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/a8ab0f18-6259-44ee-b771-69c2c16479ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

José Valim

unread,
Dec 8, 2016, 2:56:18 PM12/8/16
to elixir-l...@googlegroups.com
Hi Jeremy, we have discussed and decided to keep things as is. We believe the current defaults provides the best user experience for the majority of projects and consistently does so across all environments.

One suggestion you could possibly adopt is to check if the :dialyxir application has been started by the very beginning of your Mix tasks. If so, it means the user forgot the "runtime: false" option and you could provide them more guidance.

Thank you for the suggestion!

Reply all
Reply to author
Forward
0 new messages