Skip to content
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

setup-info field in stack.yaml not consulted #2983

Closed
ndmitchell opened this issue Feb 5, 2017 · 8 comments · Fixed by #5031
Closed

setup-info field in stack.yaml not consulted #2983

ndmitchell opened this issue Feb 5, 2017 · 8 comments · Fixed by #5031

Comments

@ndmitchell
Copy link
Contributor

Using stack 1.3.2 on Windows 64bit, I have a stack.yaml file containing setup-info: http://example.com/none.yaml. I have disabled access to raw.githubusercontent.com. If I run either stack setup or stack build then I get an error about not being able to reach raw.githubusercontent.com, rather than a 404 failing to download example.com/none.yaml. If I use the flag --setup-info-yaml with example.com then it fails witha 404 as expected. The documentation suggests these two settings are equivalent, but they don't seem to be.

@mgsloan
Copy link
Contributor

mgsloan commented Feb 27, 2017

Hmm, indeed it seems that --setup-info-yaml overrides the default url, whereas the setup-info field extends the list of configs to load.

I wonder how impactful it would be to change this semantics such that the default url doesn't get used when setup-info is manually specified. Seems like a reasonable change to me

@mgsloan mgsloan added this to the P2: Should milestone Feb 27, 2017
@borsboom
Copy link
Contributor

In the case of a inline setup-info, it probably should extend the default configs, since that's commonly used to add one custom GHC bindist (e.g. if you want to test the latest GHC release candidate). For the cases where it references an external YAML URL, you're right that the more common use case would probably be to totally override the default URL. Potentially bit confusing to have the same field behave a bit differently in these two cases though.

@AleXoundOS
Copy link

Still confusing.
I have setup-info: "http://my-local-server/stack-setup.yaml" in both config.yaml and project's stack.yaml. However none of them help in case of running stack setup. I still have to manually give --stack-setup-yaml=http://my-local-server/stack-setup.yaml option to stack setup on the first run.

@borsboom
Copy link
Contributor

I think that field expects the setup info to be inline, not point to a separate file/URL. The fact that's it's silently ignoring an entry is a bug though, and being able to point it to a separate file/URL would be a helpful feature.

@dbaynard
Copy link
Contributor

dbaynard commented Sep 1, 2018

So to resolve this issue,

  1. Supplying invalid setup-info should lead to an error (fixing the bug), and
  2. If a path is supplied (to setup-info or an equivalent key) that should be treated as the stack-setup.yaml file.

Is that correct?

@borsboom
Copy link
Contributor

borsboom commented Sep 2, 2018

Yes, I'd say (1) is required and (2) would be a nice feature but needs a bit of thought. Inline setup-info augments the downloaded setup-info, whereas the stack --setup-info-yaml replaces it, so it would be confusing to have both behaviours in the same setup-info field.

@istathar
Copy link
Contributor

@borsboom can I suggest that https://docs.haskellstack.org/en/stable/yaml_configuration/#setup-info be updated to explicitly say that you cannot use the field in ~/.stack/config.yaml / stack.yaml to override with your own setup-info.yaml file and that you have to use the command-line option?

[alternately, if there was a way to defeat the default value before appending the supplied values, that would be good too]

We just killed a lot of time trying to figure out why

setup-info: /home/username/.stack/setup-info.yaml

wasn't working. I understand now, but it is very confusing. Fortunately specifying on the command-line does work.

AfC

@borsboom
Copy link
Contributor

Alright, I clarified the docs in #4589. I agree it would be nice to support replacing it from the config file too.

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

Successfully merging a pull request may close this issue.

6 participants