New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stack new -- AesonException #2275

Closed
gitfoxi opened this Issue Jun 16, 2016 · 5 comments

Comments

Projects
None yet
4 participants
@gitfoxi

gitfoxi commented Jun 16, 2016

stack new hello-world fails with

Could not parse '/home/m/.stack/config.yaml':
AesonException "failed to parse field 'params': when expecting a Text, encountered Number instead"
See http://docs.haskellstack.org/en/stable/yaml_configuration.html.

When my config.yaml looks like

templates:
  params:
    author-email: 415fox@gmail.com
    author-name: michael fox
    category: Application
    copyright: copytright michael fox 2016
    github-username: gitfoxi
    year: 2016

Works fine if I change the year line to:

    year: "2016"

I think it's pretty clear what's going on here, but the documentation at http://docs.haskellstack.org/en/stable/yaml_configuration/ doesn't mention the year parameter. I learn about from when I run stack new with a blank config.yaml. It says:

Downloading template "new-template" to create project "hello-world" in hello-world/ ...
The following parameters were needed by the template but not provided: author-email, author-name, category, copyright, github-username, year
You can provide them in /home/m/.stack/config.yaml, like this:
templates:
  params:
    author-email: value
    author-name: value
    category: value
    copyright: value
    github-username: value
    year: value

I think it could be fixed by requiring that year be a string instead of a value or by coercing whatever value happens to be to a string using Aeson's encode function.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Jun 17, 2016

Makes sense! I'd prefer just special casing "Number" than using the encode function. Otherwise, more complicated errors could turn into complicated strings, and the yaml accepted.

@tswelsh

This comment has been minimized.

Contributor

tswelsh commented Nov 16, 2017

I took a quick look at this as another place to dip into the stack codebase. According to what's in Stack.New the year parameter is always set to the current year, unless overridden by an explicit -p year:2016 on the command line. A parameter with name year in ~/.stack/config.yaml never gets used according to:

let context = M.union (M.union nonceParams extraParams) configParams
.

Is this what you would expected? Would you ever want to use a non-current year in the config file?

However, even if the value is never used you still see the exception when parsing config.yaml. Was the suggestion to allow all parameters to be Number, or just year? The alternative is just documenting what the code does, i.e. all parameter values must be a string.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Dec 17, 2017

@tswelsh Sorry for the delay in responding, I am currently cleaning up my browser window with "TODO" stack issues.

Is this what you would expected? Would you ever want to use a non-current year in the config file?

Good question. It seems arbitrary to disallow it, so it's allowed but not recommended.

Was the suggestion to allow all parameters to be Number, or just year?

All parameters should be allowed to be Number. A similar change recently happened in hpack - sol/hpack@8aa7537#diff-87ed521fa5387e6fab1b0cdf6786eb63R76

I'm actually quite fine just forcing users to use strings. Leaning towards doing that and just making this a documentation issue. With Number, the user may not get the exact text they entered.

@tswelsh

This comment has been minimized.

Contributor

tswelsh commented Dec 23, 2017

Can this be closed off as #3701 has been merged? Sorry should have linked to this in the PR somehow

@lwm

This comment has been minimized.

Member

lwm commented Dec 23, 2017

No stress, let's close it, sure!

@lwm lwm closed this Dec 23, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment