Discuss: Should the `stack new` default template still use package.yaml?

[juhp]

General summary/comments (optional)

Correct me if I am wrong but I think/thought that package.yaml usage is deprecated or no longer recommended with stack - at least that is my understanding. However it seems stack new still creates a package.yaml file.

Steps to reproduce

$ stack new new-shiny-project
$ ls new-shiny-project

Expected

No package.yaml file to be created.

Actual

package.yaml was created.

Stack version

2.7.5

Method of installation

• An unofficial package repository: Fedora

[psibi]

Correct me if I am wrong but I think/thought that package.yaml usage is deprecated

I didn't know that and I use package.yaml extensively. Is there someplace where it's mentioned that it's deprecated ?

[mpilgrem]

As far as I know, Stack's preferred default is to use Hpack and package.yaml and that is reflected in the new-template.hsfiles template. It would not take much to create a corresponding template that excludes Hpack. The Stack command stack templates provides information about adding templates to the collection.

The basis for my understanding of the default preference is that Stack's online documentation assumes Hpack; Stack's stated goals include 'Provide easy to use tooling for Haskell development' and Hpack's design principles are consistent with 'making things easier'; Hpack is actively maintained and developed; and I thought the direction of travel, generally, was towards greater adoption of Hpack, not away from it.

[hasufell]

hpack doesn't provide much benefit these days, except for automatic module discovery.

The cabal file-format already supports conditional blocks and common stanzas for code re-use.

Additionally, I don't consider understanding two file formats instead of one an advantage. It's frequently confusing for newcomers.

Further, hpack doesn't even map all of cabal syntax correctly: sol/hpack#515

Hpack also makes reproducibility harder, see Snoymans blog post Storing generated cabal files. Now you also have to deal with generated files, glitches related to generation and issues with pull requests, cherry-picking commits, etc. etc.

[mpilgrem]

Stack, of course, works with or without using its in-built version of Hpack - depending on whether or not a package.yaml file is present. So, the discussion here is simply whether the default template used by stack new should be one with or without Hpack. A change from the status quo would require the online documentation to be conformed to the new default - not a huge task but an important one.

I do not know how best to poll opinion. I am going to change the issue title to ask the underlying question and suggest that people 'thumbs up' or 'thumbs down' @juhp's initial comment to assess sentiment.

Depending on where the balance of opinion currently falls, you could have an alternative template without-hpack (to augment the status quo) or with-hpack (a copy of the current new-template) and a consequent choice of alternative commands (either stack new <package_name>/stack new <package_name> without-hpack (the augmented status quo) or stack new <package_name>/stack new <package_name> with-hpack (the alternative)). I may seek to create those templates anyway, in the interim.

[hasufell]

@mpilgrem I suggest to cast votes both on reddit and discourse then

[mpilgrem]

I have identified something potentially relevant to this discussion:

The 2018 book Get Programming With Haskell by Will Kurt (which has an in-browser version) does not refer to Hpack in its index.

On 10 July 2022, Michael Snoyberg accepted recent pull request commercialhaskell/stack-templates#149 to add template kurt to the collection. kurt is essentially what I would have named without-hpack.

So, a user can currently command stack new <package_name> kurt and enjoy a package.yaml-free starting experience. That is, however, I think not documented anywhere that users more generally would read.