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.

[ulysses4ever]

Discussion here seems to have stalled with no consensus. I'd suggest closing this and get back when someone comes up with a proposal that would collect more support.

[mmynsted]

Have you considered a model where one could init based on a template that modifies some or all of the init criteria? If the templates were sourced from someplace like git, then people could share them with their coworkers, team, or everyone.

Without a kind of plug-in model, a solution seems unmanageable directly from the Cabal repo.

Unless cabal is changed the best solution I see is something like Vanessa McHale's project-init. It is a good solution but it replaces cabal init. A better solution would be to allow users to customize their use of cabal init, not replace it.

[ulysses4ever]

Templates would be great. Stack has them. But there's always the other side of the coin. Tailoring defaults to your liking looks like a sufficiently orthogonal task that a separate tool could be employed rather than making already huge cabal code base even bigger. Indeed, summoner goes a long way in this direction (although it doesn't have a templating mechanism). I think, cabal init has its niche: a very simple tool for one-off experiments. For anything more serious I'd use summoner or, perhaps yet unwritten, template-based tool.

Yet, if someone would volunteer to implement a light-weight (in terms of amount of code) templating support for cabal init following best practices from other language ecosystems (or, indeed, stack), I'd salute it.