Improve `cabal init` defaults

[santiweight]

Many users, including myself, get frustrated when starting a new project. The cabal init experience is very pleasant, but the defaults for packages and the generated code could be more practical:

1. cabal init should include various important packages in the default project (such as text, containers, bytestring)
2. ideally, the generated Main.hs should use some of these packages, so that there are as few "unused package" errors as possible
3. the library should generate more than one file, in order to show how to have multiple files in a cabal package
4. should the generated test file include some logic?

Is (1) possible? If so, we can come up with some more specific ideas for (2,3,4)

[ulysses4ever]

For (1), including random packages doesn’t sound useful to me. On the other hand, it’s conceivable that we could have a command-line option for packages to include. A bit unclear: what bounds to use (no bounds is a bad style). Accessing index to determine the latest version of a package during cabal init sounds bad.

[ulysses4ever]

For the rest, it’s not clear to me how far it should go (if anywhere). Do you have references for prior art in mind? Stack, npm, whatever. It’d be interesting to see what others do.

[santiweight]

We're more shooting for "not annoying". Most new users of cabal will be confused if they can't use common imports such as import Data.Text or import Data.Map qualified, which are standards by now.

Including these packages in the standard project allows both beginners and experienced users to get started on real projects with fewer frictions (most real projects use at least text and containers). That sounds very useful to me.

Bounds shouldn't matter for these core packages since they are bundled with GHC.

[Bodigrim]

For (1), including random packages doesn’t sound useful to me. On the other hand, it’s conceivable that we could have a command-line option for packages to include. A bit unclear: what bounds to use (no bounds is a bad style). Accessing index to determine the latest version of a package during cabal init sounds bad.

The idea is to add boot packages only, and probably only for app components.

[ulysses4ever]

Boot packages are a bunch of random packages that GHC happen to depend upon. I fail to see why they would "improve cabal init defaults".

[santiweight]

A common complaint I've heard is that many common packages are not included in cabal init projects. You can see similar opinions in the inspiration for this issue:

https://discourse.haskell.org/t/bringing-data-text-into-base-what-is-the-next-step/5016/40

[ulysses4ever]

Oh, that DIscourse thread… One thing that I think could be improved inside init is support for alternative preludes (preferably via mixins). The issue here is that we don't have one blessed alternative Prelude, so the user will have to choose. But adding it as a question in the interactive (and a CLI argument for both interactive or non-interactive) seems like a good idea to me. So, basically, what Richard proposes there modulo the fact that there's no standard currently.