Add 'SimplePackage' package type for cabal init

[m-renaud]

Overview

Partially addresses #5696.

Implement's @gbaz's suggestion in #5696 (comment).

This new PackageType addresses the common use case of getting a package set up as quickly as possible without needing to go through the full interactive prompt. We move the getLibOrExec prompt to the front of the list, and if SimpleProject is selected we bypass the rest of the interactive prompt and use the defaults.

This behaviour can also be invoked via: cabal init --simple

Testing

This change was manually tested, let me know if there's any automated testing for this you'd like me to update.

New cabal init behaviour:

$ cabal-dev init
Should I generate a simple project with sensible defaults?? [default: y] y

Guessing dependencies...

Generating LICENSE...
Warning: unknown license type, you must put a copy in LICENSE yourself.
Generating Setup.hs...
Generating CHANGELOG.md...
Generating Main.hs...
Generating myapp.cabal...

Warning: no synopsis given. You should edit the .cabal file and add one.
You may want to edit the .cabal file and add a Description field.

$ cat myapp.cabal 
cabal-version:       >=1.10
-- Initial package description 'myapp.cabal' generated by 'cabal init'.
-- For further documentation, see http://haskell.org/cabal/users-guide/

name:                myapp
version:             0.1.0.0
-- synopsis:
-- description:
-- bug-reports:
-- license:
license-file:        LICENSE
author:              Matt Renaud
maintainer:          matt@m-renaud.com
-- copyright:
-- category:
build-type:          Simple
extra-source-files:  CHANGELOG.md

library
  -- exposed-modules:
  -- other-modules:
  -- other-extensions:
  build-depends:       base >=4.12 && <4.13
  -- hs-source-dirs:
  default-language:    Haskell2010

executable myapp
  main-is:             Main.hs
  -- other-modules:
  -- other-extensions:
  build-depends:       base >=4.12 && <4.13
  -- hs-source-dirs:
  default-language:    Haskell2010

$ cabal-dev init --simple

Guessing dependencies...

Generating LICENSE...
Warning: unknown license type, you must put a copy in LICENSE yourself.
Generating Setup.hs...
Generating CHANGELOG.md...
Generating Main.hs...
Generating myapp.cabal...

Warning: no synopsis given. You should edit the .cabal file and add one.
You may want to edit the .cabal file and add a Description field.

Documentation

• New command line argument --simple documented in Distribution.Client.Setup
• CHANGELOG to be updated once changes finalized
• Cabal user guide to be updated once changes finalized

Follow-ups (out of scope of this PR)

• Select more "modern" defaults in getLibOrExec (such as using src/ dir for libraries and app/ dir for Main.hs, default to the most recent 2.4 cabal version, create cabal.project file, etc.)

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.
• If the change is docs-only, [ci skip] is used to avoid triggering the build bots.

Please also shortly describe how you tested your change. Bonus points for added tests!

/cc @gbaz @23Skidoo @hvr

[23Skidoo]

/cc @byorgey

[23Skidoo]

Is this basically the same as running cabal init -n --is-executable?

[m-renaud]

Currently it's --is-libandexe, but the idea is for it to eventually fill in a more complete package scaffolding (lib, exe, test suite, etc), and also use more modern defaults.

Also, this provides a way of short circuiting the interactive prompt to give a nice default experience for beginners while only running cabal init.

[23Skidoo]

Maybe make it a single yes/no choice before the package type choice then? Something like: "Should I just generate a simple project with sensible defaults or let you tweak the fine-grained settings? (yes/no)" . It's IMO a bit unclear what a "simple package" is and why one needs to choose between it and a lib/exe.

Adding an option for generating a test suite/benchmark and "more modern defaults" sound like good ideas in general, I think all package types could benefit from that.

[m-renaud]

@23Skidoo Updated, see PR description for new prompt.

Also, to sync with updated master branch do you just do a merge or do you rebase on top of master?

[m-renaud]

Let me know if there's anything else you'd like me to change. I have some other improvements I'd like to make on top of this so if we could get this merged in soon that would be great :)

[23Skidoo]

Usually PRs are rebased to get rid of spurious merge commits.

[m-renaud]

I ended up using GitHub's web merge tool, but good to know. This PR is ready for review/merge now.

[m-renaud]

@23Skidoo the one CI failure GHCVER=7.10.3 was due to a timeout. I've restarted the job but that probably doesn't need to block.

[m-renaud]

Friendly ping :)

[23Skidoo]

LGTM.

[23Skidoo]

Merged, thanks!

[m-renaud]

Thanks @23Skidoo for the review! There's some more cabal init improvements incoming if you have some time for more reviews :)