Closed ivnsch closed 6 years ago
Would you like to force a sync? THIS WILL REMOVE ANY LOCAL CHANGES! [y/N]: N
This line makes me wonder if there are any local changes that might be affecting the build. Did you basically install it once, run into the problem, then run the installer again to capture the output? Then you chose "N" basically because nothing had changed between runs?
Warning: Installed version of cabal-install (2.0.0.0) is newer than stack has been tested with. If you run into difficulties, consider downgrading.
I haven't tried the installer with cabal-install 2 yet, so there could be a possible incompatibility. Seeing The following lines from cabal-install output could not be parsed
makes me even more suspicious. Can you try running the installer on a fresh machine either on Docker or Digital Ocean or something that has cabal-install 2? Perhaps that will reproduce the problem.
same here
"stack --resolver lts-7.9 install ghc-mod --install-ghc --verbosity warning" failed with error 1
*** setup_haskell.hs failed with error 1.
*** Aborting...
if I run
$ stack --resolver lts-7.9 install ghc-mod --install-ghc --verbosity warning
$ echo $?
0
EDIT: I edited the script and got:
Setting up GHC if needed...
Stack bin path: /Users/blender/.local/bin
Stack global path: /Users/blender/.stack
Stack global config location: /Users/blender/.stack/global-project/stack.yaml
Stack resolver: lts-7.9
/Users/blender/.config/haskell-vim-now/.stack-bin -> /Users/blender/.local/bin
Installing helper binaries...
stack --resolver lts-7.9 install ghc-mod --install-ghc --verbosity warning
Plan construction failed.
Edit: the stack --resolver ... command fails if run not in a stack project directory. For example if I run stack --resolver lts-7.9 install ghc-mod --install-ghc --verbosity warning
in my home dir it fails. If I run it in a project dir it succeeds .
I'd like to play around with this one when I get a chance. Please feel free to assign to me if you'd like. Definitely seems like it could be a cabal 2 thing.
@i-schuetz & @blender: Would you please locate the stack root directory on your machines via:
stack --verbosity 0 path --stack-root
Then from that dir, open up global-project/stack.yaml
and let us know the resolver
version that is in that file?
$ stack --verbosity 0 path --stack-root | xargs -I dir cat dir/global-project/stack.yaml
# This is the implicit global project's config file, which is only used when
# 'stack' is run outside of a real project. Settings here do _not_ act as
# defaults for all projects. To change stack's default settings, edit
# '/Users/blender/.stack/config.yaml' instead.
#
# For more information about stack's configuration, see
# https://github.com/commercialhaskell/stack/blob/release/doc/yaml_configuration.md
#
flags: {}
extra-package-dbs: []
packages: []
extra-deps: [cabal-helper-0.6.1.0, pure-cdb-0.1.1]
resolver: lts-9.11
Thank you, @blender. What about:
cabal --version
stack --version
If you have cabal 2 and that's what might be biting us here, we can try a clean VM that forces usage of cabal 2.
As a side note, seeing the extra-deps: [cabal-helper-0.6.1.0, pure-cdb-0.1.1]
is a decent indicator the problem could be stemming from the state your system is in from an older run of the haskell-vim-now
installer. In a reasonably older version of haskell-vim-now
, it had to do some stack.yaml weirdness for pinning down pure-cdb
. I believe that was a transitive dependency or something. It is no longer needed.
Not that it matters/is bad if pure-cdb
is in your global stack config - just a callout that it's possible the changes that have been made to haskell-vim-now
are not backwards compatible with older installs.
Update: For reference, here's some comments from a year or two ago about pure-cdb
:
$ cabal --version
-bash: cabal: command not found
$ stack --version
Version 1.5.1 x86_64 hpack-0.17.1
Well, apparently something does make a difference.
I removed the extra-deps and run bash /tmp/haskell-vim-now.sh
(I think previously I was running just /tmp/haskell-vim-now.sh
and it got somewhat further. Note that I put some debug prints around where it was stopping previously
$ bash /tmp/haskell-vim-now.sh
--> Existing Haskell-Vim-Now installation detected at /Users/blender/.config/haskell-vim-now.
--- Syncing Haskell-Vim-Now with upstream...
--- No new packages needed for install...
--- Checking ctags' exuberance...
--- Setting git to use fully-pathed vim for messages...
--- Testing for broken Ruby interface in vim...
--- Test passed. Ruby interface is OK.
--- Backing up current vim config using timestamp 20171110_102428...
/Users/blender/.config/haskell-vim-now/backup/.vim.20171110_102428
/Users/blender/.config/haskell-vim-now/backup/.vimrc.20171110_102428
--- Creating vim config symlinks
~/.vimrc -> /Users/blender/.config/haskell-vim-now/.vimrc
~/.vim -> /Users/blender/.config/haskell-vim-now/.vim
--- Installing plugins using vim-plug...
HERE
/Users/blender/.config/haskell-vim-now/scripts/setup_haskell.hs
HvnArgs {hvnArgsNoHoogleDb = False, hvnArgsNoHelperBinaries = False}
Setting up GHC if needed...
FilePath "/Users/blender/.stack/global-project/stack.yaml"
Just (Line "resolver: lts-9.11")
"lts-9.11"
Stack bin path: /Users/blender/.local/bin
Stack global path: /Users/blender/.stack
Stack global config location: /Users/blender/.stack/global-project/stack.yaml
Stack resolver: lts-9.11
/Users/blender/.config/haskell-vim-now/.stack-bin -> /Users/blender/.local/bin
Installing helper binaries...
stack --resolver lts-9.11 install ghc-mod --install-ghc --verbosity warning
stack --resolver lts-9.11 install cabal-install --install-ghc --verbosity warning
Completed 7 action(s).
stack --resolver lts-8.14 install hindent --install-ghc --verbosity warning
Completed 19 action(s).
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
, hasktags
, hlint
, hoogle
, hscope
, pointfree
, pointful
default-language: Haskell2010
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- dependencies.cabal
Selecting the best among 11 snapshots...
Downloaded lts-9.12 build plan.
Selected mirror https://s3.amazonaws.com/hackage.fpcomplete.com/
Downloading timestamp
Downloading snapshot
Updating index
Updated package list downloaded
Populated index cache.
* Partially matches lts-9.12
apply-refact not found
- dependencies requires -any
codex not found
- dependencies requires -any
hasktags not found
- dependencies requires -any
hscope not found
- dependencies requires -any
pointfree not found
- dependencies requires -any
Downloaded nightly-2017-11-10 build plan.
* Rejected nightly-2017-11-10
ghc-8.2.1 cannot be used for these packages:
- dependencies
base version 4.10.0.0 found
- dependencies requires >=4.9 && <4.10
Downloaded lts-8.24 build plan.
* Partially matches lts-8.24
apply-refact not found
- dependencies requires -any
codex not found
- dependencies requires -any
hasktags not found
- dependencies requires -any
hscope not found
- dependencies requires -any
pointfree not found
- dependencies requires -any
Downloaded lts-7.24 build plan.
* Partially matches lts-7.24
codex not found
- dependencies requires -any
hasktags not found
- dependencies requires -any
hscope not found
- dependencies requires -any
pointfree not found
- dependencies requires -any
Downloaded lts-6.35 build plan.
* Rejected lts-6.35
ghc-7.10.3 cannot be used for these packages:
- dependencies
base version 4.8.2.0 found
- dependencies requires >=4.9 && <4.10
* Rejected lts-5.18
ghc-7.10.3 cannot be used for these packages:
- dependencies
base version 4.8.2.0 found
- dependencies requires >=4.9 && <4.10
* Rejected lts-4.2
ghc-7.10.3 cannot be used for these packages:
- dependencies
base version 4.8.2.0 found
- dependencies requires >=4.9 && <4.10
* Rejected lts-3.22
ghc-7.10.2 cannot be used for these packages:
- dependencies
base version 4.8.1.0 found
- dependencies requires >=4.9 && <4.10
* Rejected lts-2.22
ghc-7.8.4 cannot be used for these packages:
- dependencies
base version 4.7.0.2 found
- dependencies requires >=4.9 && <4.10
* Rejected lts-1.15
ghc-7.8.4 cannot be used for these packages:
- dependencies
base version 4.7.0.2 found
- dependencies requires >=4.9 && <4.10
* Rejected lts-0.7
ghc-7.8.3 cannot be used for these packages:
- dependencies
base version 4.7.0.1 found
- dependencies requires >=4.9 && <4.10
Selected resolver: lts-7.24
*** Resolver lts-7.24 will need external packages:
codex not found
- dependencies requires -any
hasktags not found
- dependencies requires -any
hscope not found
- dependencies requires -any
pointfree not found
- dependencies requires -any
Using resolver: lts-7.24
Solver requires that cabal be on your PATH
Try running 'stack install cabal-install'
"stack init --solver --install-ghc" failed with error 1
OK
*** setup_haskell.hs failed with error 1.
*** Aborting...
setup_haskell.hs failed for me as well. I have lts-8.23 as my default global stack resolver. So cabal-install
is installed with that resolver. However, the solver picks a resolver that needs cabal-2:
Downloaded nightly-2017-11-17 build plan.
Unable to parse cabal file: FromString "This package requires at least Cabal version 2.0" Nothing
cueball:~ $ cabal --version
cabal-install version 1.24.0.2
compiled using version 1.24.2.0 of the Cabal library
We need to make sure that the cabal we install and the cabal that the chosen resolver needs are compatible.
I propose that we use the --resolver
option during solving to pin the resolver for the solver, to the default global resolver. Once we do that the solver may solve it with some extra dependencies in the stack.yaml. We can then install all these binaries with the solver generated stack.yaml instead of choosing a resolver that can satisfy all these deps without extra-deps. It is possible that none of the resolver can satisfy what we want without extra-deps. Therefore building with a solver generated stack.yaml is a more predictable option.
Another problem is that this install overwrites the already installed binaries in .local/bin without asking the user and it may throw surprises to the user later. We should instead not install what is already installed. That has two fold advantages, 1) we do not break a user's setup by silently changing a binary 2) users can pre-install these binaries to avoid any install problems like the one we are dealing with in this issue.
I installed and ran the script as described in the readme. What's going on?