Skip to content

Get LTS-8.5 working #238

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

Merged
merged 10 commits into from
Apr 7, 2017
Merged

Get LTS-8.5 working #238

merged 10 commits into from
Apr 7, 2017

Conversation

jship
Copy link
Collaborator

@jship jship commented Mar 22, 2017

Pin a few things to older LTS versions to make install from scratch less painful when using LTS-8.

Move hindent to the main install list as it no longer requires a specific pinned nightly (Hindent 5 is in LTS-8.5).

Call hoogle generate instead of hoogle data.

@jship
Copy link
Collaborator Author

jship commented Mar 23, 2017

@begriffs: Played around with this to try and get travis working, but Travis seems stuck on using LTS-7.2. I checked out the travis config and it doesn't look like haskell-vim-now is testing multiple GHC/LTS versions.

Is there a way to reset this in the Travis build box(es) so it starts using LTS-8.5? If so, I'll revert the 3 commits I put in today from experimentation.

@begriffs
Copy link
Owner

Thansk @jship, whenever I see this icon on a pull request I know there are going to be great changes!
the icon

I can clear the build cache on CI, but wondering whether it is currently simulating a problem that an actual user would experience if they had previously installed haskell-vim-now. What do you think?

@jship
Copy link
Collaborator Author

jship commented Mar 23, 2017

Thank you!

Great point about previous installs. I started from scratch for GHC8 when I made this PR, and will experiment with getting Travis happy on the older LTS. Shooting to play around with it tonight or early next week.

@jship
Copy link
Collaborator Author

jship commented Mar 24, 2017

Travis #115 build "passed" but timed out after everything completed successfully. Had to download a couple different GHC versions, which ate up time.

Squashed the commits and Travis #116 is going now. It still had to download a GHC and rebuild helper binaries which is strange - thought they would've been cached.

Maybe Travis doesn't cache on timeout?

It's painful on the initial install to have to get a couple different GHC versions, but from my testing, this will work fine for LTS-7.3 (what Travis is using) and LTS-8.5 (what I'm using). Users hopefully won't have to muck around in their global stack.yaml's.

@SX91
Copy link
Contributor

SX91 commented Mar 27, 2017

@jship that is a bad idea to overcomplicate installer that way.
@begriffs need some better and clearer way to "fix" this.

@begriffs
Copy link
Owner

We may just want to have a dependencies.cabal and stack.yaml file for the the helper binaries.

Here's a cabal file to declare the dependencies:

name:                dependencies
version:             0.1.0.0
synopsis:            helper binaries for vim
homepage:            https://github.com/begriffs/haskell-vim-now
license:             MIT
author:              Joe Nelson
maintainer:          cred+github@begriffs.com
category:            Development
build-type:          Simple
cabal-version:       >=1.10

library
  build-depends:       base >=4.9 && <4.10
                     , apply-refact
                     , codex
                     , ghc-mod
                     , hasktags
                     , hlint
                     , hoogle
                     , hscope
                     , pointfree
                     , pointful
  default-language:    Haskell2010

When I just ask cabal: cabal install --only-dependencies --reorder-goals and then cabal freeze I get this list of pinned versions that I think is able to install all the newest binaries: https://gist.github.com/begriffs/d655e8628e7f14f8f7ab51e6762190fc

Alternately doing a stack init --solver for the cabal file produces

resolver: lts-7.20
packages:
- '.'
extra-deps:
- codex-0.5.0.2
- hasktags-0.69.3
- hscope-0.4.3
- machines-directory-0.2.1.0
- machines-io-0.2.0.13
- pointfree-1.1.1.2
flags: {}
extra-package-dbs: []

@jship
Copy link
Collaborator Author

jship commented Mar 28, 2017

@begriffs Great idea - I'll experiment with this sometime this week.

@jship
Copy link
Collaborator Author

jship commented Mar 30, 2017

Hmm, Travis failed but local install passed for me. Will try again locally using LTS-7.3 to match Travis.

@jship
Copy link
Collaborator Author

jship commented Mar 30, 2017

Coming from an older version of stack: commercialhaskell/stack#2969

invalid-cabal-flag-settings was removed from stack list-dependencies output as a special case.

@jship
Copy link
Collaborator Author

jship commented Mar 30, 2017

Travis failed on rts - another bogus dependency from stack list-dependencies. Let's see how it goes with the latest commit to filter it out too.

@jship
Copy link
Collaborator Author

jship commented Mar 30, 2017

Hooray! Travis checks out.

@mingyuguo
Copy link

This version works great! (The master branch unfortunately doesn't work for me)

@jiakai0419
Copy link

@mingyuguo how to use this version.

@mingyuguo
Copy link

Clone it into .config/haskell-vim-now
Run the original script with one change (comment out the line that calls check_repo_change around line 95)

@jship
Copy link
Collaborator Author

jship commented Apr 4, 2017

You can clone it anywhere and then specify the location when you run the install script with --repo.

I have my fork at ~/git/haskell-vim-now. I usually run:

cd ~/git/haskell-vim-now
bash install.sh --repo .

scripts/setup.sh Outdated
stack --resolver nightly-2016-12-28 install hindent --verbosity warning ; RETCODE=$?
[ ${RETCODE} -ne 0 ] && exit_err "hindent installation failed with error ${RETCODE}."
# Install ghc-mod via active stack resolver for maximum out-of-the-box compatibility.
stack --resolver ${STACK_RESOLVER} install ghc-mod --verbosity warning ; RETCODE=$?
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you include cabal-install in this one as well rather than having a separate step below?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No problem.

scripts/setup.sh Outdated
stack --resolver ${STACK_RESOLVER} install ghc-mod --verbosity warning ; RETCODE=$?
[ ${RETCODE} -ne 0 ] && exit_err "Installing ghc-mod failed with error ${RETCODE}."

# Install hindent via pinned LTS to ensure we have version 5.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're right about this one...I tried adding hindent >= 5.0 to the dependencies cabal file and that breaks the solver. Guess we have to do it separately like you did.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's a little frustrating that we have to manually install hindent. The vim config expects hindent 5 and I'd rather not regress to hindent 4 to match the solver version.

@begriffs
Copy link
Owner

begriffs commented Apr 4, 2017

This is really nice work. See if you can combine the ghc-mod and cabal-install steps and we'll be good to merge.

@jship
Copy link
Collaborator Author

jship commented Apr 4, 2017

Was so close to completing in Travis: Travis build log.

😃

@begriffs
Copy link
Owner

begriffs commented Apr 4, 2017

Weird, it seems totally finished, I wonder if travis is not detecting a successful return code or something. Or maybe it's just a second or two too short...

Also do you know how to suppress this repeated message?

Warning (added by new or init): Specified resolver could not satisfy all dependencies.
Some external packages have been added as dependencies.
You can suppress this message by removing it from stack.yaml 

@jship
Copy link
Collaborator Author

jship commented Apr 4, 2017

To suppress that message, we'll have to remove it from the generated stack.yaml created by stack during the dependency solving. I can sed it out of there.

@jship
Copy link
Collaborator Author

jship commented Apr 4, 2017

It was successful again but timed out based on Travis' 50-minute upper bound for jobs: https://docs.travis-ci.com/user/customizing-the-build#Build-Timeouts

The install portion took around 43 minutes according to Travis and the durations of the other phases of the job do not add up to 50 minutes. Strange.

@begriffs: Should we temporarily disable the hoogle generation and see if it passes? Maybe that way we could get the stack build artifacts cached to speed up subsequent builds.

@begriffs
Copy link
Owner

begriffs commented Apr 4, 2017

Temporarily disabling hoogle sounds smart, give it a try.

@begriffs
Copy link
Owner

begriffs commented Apr 5, 2017

That got it working! When you're ready, put hoogle back and we'll cross our fingers.

@begriffs
Copy link
Owner

begriffs commented Apr 6, 2017

Maybe the hoogle generation should be disabled when running on CI.

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

Successfully merging this pull request may close these issues.

5 participants