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

Listing flags in stack.yaml gives "Invalid flag specification" #3374

Closed
leohaskell opened this Issue Aug 22, 2017 · 6 comments

Comments

Projects
None yet
3 participants
@leohaskell
Copy link

leohaskell commented Aug 22, 2017

I'd expect listing the flags in stack.yaml as in

flags:
  library1:
    flag-name1: true
  library2:
    flag-name2: false

to has the same effect as

stack build --flag library1:flag-name1 --flag library2:-flag-name2

However, the first one fails with "Invalid flag specification" and wants me to add library1 and library2 to the extra-deps field, while the second one succeeds.

EDIT: This happens with stack version 1.5.1 on Windows, and I'll try it on Linux too.

@mgsloan

This comment has been minimized.

Copy link
Collaborator

mgsloan commented Aug 22, 2017

Yeah, I recall seeing this distinction in the code. With CLI flags, it does implicit upgrade of packages to being extra-deps. Whereas with the configuration, you need to be explicit about the upgrade of packages to extra-deps.

I think this is a reasonable thing to expect, it potentially makes the behavior of flags clearer to the user. Though, if implicit snapshots gets implemented - #3330 - it will probably make sense to drop this requirement.

That said, the error should definitely be better than Invalid flag specification. I see two possible resolutions:

  1. Drop the requirement. One issue with this is that configurations which don't follow the requirement won't work with older stack.

  2. Make the error message clearer. Leaning towards this.

@leohaskell

This comment has been minimized.

Copy link

leohaskell commented Aug 23, 2017

Isn't it better for the upgrade to be implicit? If it's not, every time you want to change the lts version in the resolver field, you'll have to check the versions of the packages in this concrete lts version and update the extra-deps field.

EDIT: As a user, I'd expect stack to automatically pick the matching lts versions of the mentioned packages.

@mgsloan

This comment has been minimized.

Copy link
Collaborator

mgsloan commented Aug 23, 2017

Yeah, that's reasonable. At the minimum, should have the error message give the line to add to extra-deps.

@snoyberg

This comment has been minimized.

Copy link
Contributor

snoyberg commented Aug 24, 2017

I just noticed this issue in the Haskell Weekly newsletter. I may have accidentally implemented this already on master, thinking that the requested behavior was the current behavior in 1.5 (which apparently it isn't). So before anyone jumps in to implement, simply testing against master would be good.

@leohaskell

This comment has been minimized.

Copy link

leohaskell commented Aug 25, 2017

Yes, it's implemented in master.
So, I'm closing the issue : )

NOTE: Maybe someone should add this to the unreleased changes

@leohaskell

This comment has been minimized.

Copy link

leohaskell commented Oct 11, 2017

EDIT: Sorry for the messed up issue history.

@leohaskell leohaskell reopened this Oct 11, 2017

@leohaskell leohaskell closed this Oct 11, 2017

@leohaskell leohaskell reopened this Oct 11, 2017

@leohaskell leohaskell closed this Oct 11, 2017

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