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

[Feature request] Overwrite resolver version for Haskell solutions #13

Closed
Javran opened this issue Feb 26, 2021 · 3 comments · Fixed by #15
Closed

[Feature request] Overwrite resolver version for Haskell solutions #13

Javran opened this issue Feb 26, 2021 · 3 comments · Fixed by #15
Assignees
Labels
enhancement New feature or request track-script Related to a track's script

Comments

@Javran
Copy link
Contributor

Javran commented Feb 26, 2021

The current issue when reviewing an old solution is that the resolver is set to a very old version, which would download a different old version of compiler together with some outdated packages, all need to be compiled, so to avoid that I ended up just editing stack.yaml as the first step for running tests.

I suggest adding an environment variable, say EXERCISM_HASKELL_STACK_RESOLVER=lts-16.21,
when this value is set to non-empty values, solution's stack.yaml's content will be overwritten to resolver: $EXERCISM_HASKELL_STACK_RESOLVER

@PaulDance
Copy link
Owner

PaulDance commented Mar 3, 2021

Hi @Javran, thanks for the suggestion!

A small doubt though: aren't such configuration options the whole point for reproducible builds? To me, it ensures that everything works correctly, as it should, especially for dependencies but also for the compiler itself it seems in Haskell. Are you sure that overwriting this automatically would never break anything? Also, how heavy is a resolver download? I would say less than five megabytes would not be worth the trouble.

If you still wish the feature to be added, then I would appreciate a PR: I don't really master every track environment, so testing the solution yourself would be preferable. Also, is there any configuration value for resolver that specifies "the latest LTS" or even "the latest nightly"? That would remove the need for any environment variables. Finally, if it is in fact necessary, I think using XR as a prefix for the environment variables instead of EXERCISM would bring less confusion.

@Javran
Copy link
Contributor Author

Javran commented Mar 3, 2021

I'm 99% sure overwriting stack.yaml won't affect much: even for my own most complicated projects, my stack.yaml consists of just a resolver version, a list of packages (which won't be the case as every exercise is supposed to build as a standalone package), and a list of extra dependencies that is not resolved by resolver (I don't think this is needed for the exercise, nor do I think it's encouraged). But for that 1% I want to leave it as an option, if the enviroment variable is not set, this overwrite won't happen.

While changing resolver isn't always expensive, changing resolver when there is a ghc version change is - my ~/.stack/programs/x86_64-linux/ghc-tinfo6-8.8.4/lib/ghc-8.8.4 directory, which includes all platform libraries (so this does not count libraries not shipped with Haskell platform itself) of ghc 8.8.4 takes 1.8G.

While it's possible to determine latest LTS version, exercism/haskell does use a fixed version of LTS, but there isn't a good way to find that version, in either case, I'd prefer just leaving this as an option to the user rather than complicating xr.

Edit: forget to mention, feel free to assign me to this bug, I'm happy to take a look.

@PaulDance
Copy link
Owner

Alright, I understand the situation then, thanks for the explanation. You can start working on it 😉

@PaulDance PaulDance added enhancement New feature or request track-script Related to a track's script labels Mar 3, 2021
Javran added a commit to Javran/xr that referenced this issue Mar 4, 2021
Closes PaulDance#13.

This patch also bundled some other changes:

- `-Wall` to `--ghc-options -Wall` as this is supposed to be
pased to GHC (stack can't recognize this flag)
- Removed `--trace` as it tends to be verbose and messes up hspec's output.
Javran added a commit to Javran/xr that referenced this issue Mar 4, 2021
Closes PaulDance#13.

This patch also bundled some other changes:

- `-Wall` to `--ghc-options -Wall` as this is supposed to be
pased to GHC (stack can't recognize this flag)
- Removed `--trace` as it tends to be verbose and messes up hspec's output.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request track-script Related to a track's script
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants