Create a bare project by default (no supervisor)

[devinus]

A lot of Alchemists today (even experienced ones) seem confused about when they should keep the supervisor mix new creates for them. I believe we should make people think about when they need a real application in the first place versus making them question if they should remove it.

Examples of new apps that should be library apps but include the default (useless) supervisor and start themselves as real applications:

https://github.com/phoenixframework/phoenix/blob/master/lib/phoenix/supervisor.ex
https://github.com/phoenixframework/ex_conf/blob/master/lib/ex_conf/supervisor.ex
https://github.com/nurugger07/inflex/blob/master/lib/inflex/supervisor.ex
https://github.com/knewter/exdrone/blob/master/lib/exdrone/supervisor.ex

Taken from a random smattering of https://github.com/search?l=elixir&p=1&q=stars%3A%3E1&s=updated&type=Repositories, sorry I can't PR everybody.

@chrismccord @nurugger07 @knewter

[chrismccord]

This is a good discussion. In Phoenix's case, I wasn't sure which route to go supervisor wise, but I agree ExConf should not have the useless superviser. I left it out of carelessness after mix new. @devinus What ideas do you have for making people think about real applications vs libs? I think docs highlighting each case might be all that's necessary. Otherwise, we could require something like mix new.app mix new.lib instead of mix new vs mix new --bare?

[devinus]

@chrismccord I'm thinking we have mix new (creates a library app, the default), and mix new --supervisor (has the application callback in mix.exs and starts a supervisor, the functionality mix new has today).

A cursory glance at a lot of popular Elixir projects in that link leads me to believe that a majority of the new projects should be library apps but a majority of those are starting the useless supervisor. (I wish I had the time to PR all of them, but I just saw way too many.)

[wilmoore]

👍

[fishcakez]

👎 The ratio on github is not representative:

• Elixir is relatively new and so prone to having people race to write library applications that already exist in every other language (like json encoders).
• Elixir is relatively new so open source projects there is a higher ratio of relatively basic projects for now.
• Library applications are more likely to be open sourced due to there more general purpose - and one needs these to write more complex ones.
• It is faster to delete in the cases where it's not needed than it is to write it where it is.

[alco]

It is faster to delete in the cases where it's not needed than it is to write it where it is.

True, but it'd be annoying to do this every time.

What about adding another required argument to mix new?

• mix new app <path> -- creates an application template with supervisor (default today)
• mix new lib <path> -- create a library template without applications in mix.exs

This will be helpful both for beginners and adepts. Even if a beginner doesn't make the right choice at first, they will at least try to learn the difference.

It's like using Go-style error ignoring (val, _ = some_func()) vs explicitly handling the error part of the option type (case some_func() do {:ok, value} -> value; :error -> ...). If you choose the first one (the current behaviour of mix), you'll inevitably get libraries with useless supervisors (or missing supervisors if the default is flipped).

[josevalim]

That's an interesting option @alco. Should it be new app and new lib or new.app and new.lib?

[fishcakez]

I think lib/app is a bad choice because they are both applications and anything that suggests otherwise is misleading.

[josevalim]

Maybe the names are bad but the point is about forcing the users to make a decision which one they won't instead of picking one as default.

[matheusml]

What about keeping the old mix new, which creates a default project,
but adding the options that @alco said.

Something like:

    mix new my_project
    mix new app my_project
    mix new lib my_project
    mix new webapi my_project

[bitwalker]

I like @matheusml's suggestion, since it mirrors lein quite nicely with how it handles custom project templates. One could imagine a mix new phoenix my_project command which would generate a blank phoenix project.

I do think using lib to refer to bare apps is a bad idea, but we talked that to death in IRC the other day.

[knewter]

I like @matheusml's suggestoin as well, and especially if it would include custom templating later :)