HVN fails to build on fresh Ubuntu GNOME 16.10

[Tientuine]

This is on a freshly installed and updated Ubuntu GNOME 16.10.

I've installed HVN successfully on my primary laptop, and I don't understand the problem here. I have installed none of GHC, Haskell Platform, or Stack prior to HVN... I figured I would allow HVN to handle everything in this instance. Any suggestions are greatly appreciated.

Here is the terminal output:

user@host:~$ bash /tmp/haskell-vim-now.sh
ENV: [HVN_INSTALL_BASIC=]
--> No previous installations detected.
--- Installing Haskell-Vim-Now from https://github.com/begriffs/haskell-vim-now.git ...
Cloning into '/home/user/.config/haskell-vim-now'...
remote: Counting objects: 998, done.
remote: Total 998 (delta 0), reused 0 (delta 0), pack-reused 998
Receiving objects: 100% (998/998), 327.21 KiB | 0 bytes/s, done.
Resolving deltas: 100% (610/610), done.
Checking connectivity... done.
--- Installing system packages [libcurl4-openssl-dev] using [APT]...
--- Installing with apt-get...
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Skipping libcurl4-openssl-dev, it is already installed and upgrade is not set.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
--- Checking ctags' exuberance...
--- Setting git to use fully-pathed vim for messages...
--- Installing vim-plug
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 71606  100 71606    0     0   146k      0 --:--:-- --:--:-- --:--:--  146k
--- Backing up current vim config using timestamp 20170219_102833...
--- Creating vim config symlinks
	~/.vimrc -> /home/user/.config/haskell-vim-now/.vimrc
	~/.vim   -> /home/user/.config/haskell-vim-now/.vim
--- Installing plugins using vim-plug...

make -f make_unix.mak
make[1]: Entering directory '/home/user/.config/haskell-vim-now/.vim/bundle/vimproc.vim'
cc -W -O2 -Wall -Wno-unused -Wno-unused-parameter -std=gnu99 -pedantic -shared -fPIC  -o lib/vimproc_linux64.so src/proc.c -lutil
make[1]: Leaving directory '/home/user/.config/haskell-vim-now/.vim/bundle/vimproc.vim'
 
--- Setting up GHC if needed...
Downloaded lts-8.1 build plan.    
Updating package index Hackage (mirrored at https://github.com/commercialhaskell                                                                                Fetched package index.    
Populated index cache.    
Downloaded ghc-nopie-8.0.2.                                      
Unpacking GHC into /home/user/.stack/programs/x86_64-linux/ghc-nopie-8.0.2.temp/                                                                                Installed GHC.     
	Stack bin path: /home/user/.local/bin
	Stack global path: /home/user/.stack
	Stack global config location: /home/user/.stack/global-project/stack.yaml
	Stack resolver: lts-8.1
	/home/user/.config/haskell-vim-now/.stack-bin -> /home/user/.local/bin
--- Installing helper binaries...
Plan construction failed.
*** Binary installation failed with error 1.
*** Aborting...

[Tientuine]

Edit: I should clarify that the output shown above is from my second attempt to run the installer script. That is why the package dependencies are already installed. However, the first attempt resulted in the same error. Being a totally fresh OS install, my terminal history was set to the default, which was too small to scroll back and copy the entire output from the first attempt.

[Tientuine]

I've just noticed that the /home/user/.local/bin directory is empty. This seems like a problem, since haskell-vim-now/.stack-bin points to there, but there are no stack binaries in /home/user/.local/bin.

[Tientuine]

I originally didn't feel I had time to try and debug this, but then I figured I should at least try to get a little more info. The useful error messages from stack are suppressed when running the HVN setup script, so I tried manually to install the helper binaries using the exact command that the setup script was using.

The result included the following messages:

user@host:~$ stack --resolver lts-8.1 install ghc-mod hlint hasktags hscope pointfree pointful hoogle apply-refact machines-directory-0.2.0.9 machines-io-0.2.0.13 codex-0.5.0.2

Error: While constructing the build plan, the following exceptions were encountered:

In the dependencies for codex-0.5.0.2:
    directory-1.3.0.0 must match >=1.2.0.1 && <1.3 (latest applicable is 1.2.7.1)
    http-client-0.5.5 must match >=0.4 && <0.5 (latest applicable is 0.4.31.2)
    wreq must match >=0.3.0.1 && <0.5, but the stack configuration has no specified version
         (latest applicable is 0.4.1.0)

In the dependencies for hasktags-0.69.2.1:
    directory-1.3.0.0 must match >=1.1 && <1.3 (latest applicable is 1.2.7.1)

In the dependencies for hscope-0.4.3:
    haskell-src-exts-1.18.2 must match ==1.17.* (latest applicable is 1.17.1)

In the dependencies for machines-directory-0.2.0.9:
    directory-1.3.0.0 must match >=1.2 && <1.3 (latest applicable is 1.2.7.1)

In the dependencies for pointfree-1.1.1.2:
    haskell-src-exts-1.18.2 must match ==1.17.* (latest applicable is 1.17.1)

Recommended action: try adding the following to your extra-deps in /home/user/.stack/global-project/stack.yaml:
- wreq-0.4.1.0

You may also want to try the 'stack solver' command
Plan construction failed.

Not sure if I'm interpreting this correctly, but it seems that stack is looking for more recent versions of several packages than are available via the lts-8.1 resolver. I'm not well-versed in stack, just started using it fairly recently.

[begriffs]

Haskell-vim-now consults global stack config for your system to determine which "resolver" to use. It looks like new stack installations are choosing LTS 8.1. Each Stack resolver pins the versions of all Haskell packages to versions that are known to all work together. However not all packages/versions are registered there, for instance codex does not appear in the list for LTS 8.1. Hence we add version constraints (codex-0.5.0.2) in the install command so that Stack can attempt to pick that version.

However the constraints in codex-0.5.0.2 clash with the versions pinned by LTS 8.1.

I'd advise finding your global stack config by running stack --verbosity 0 path --config-location. Next edit the file to choose an older resolver like resolver: 7.16. This doesn't mean your projects can't use a newer GHC version, just that the helper tools will be built using an earlier version.

The only troublesome spot will be that I bet ghc-mod will not work properly because it is very picky that the version of cabal-install with which it was built matches that of the project it is inspecting.

Give the LTS downgrade a try and let me know. If it goes well I could temporarily hard-code that version in the installer until projects like codex are updated to be compatible with LTS 8.

[Tientuine]

That seemed to do the trick, thanks again @begriffs . So, for my own understanding, this happened because HVN referenced the codex package, but the most recent version of that package has dependencies that don't match up with the latest resolver version?

[begriffs]

That's right. :)

[tsoernes]

I can't get this to work. I have tried lts-7.20, lts-7.19, ghc-7.10.3 and they all yield:

--- Installing helper binaries...
Plan construction failed.
*** Binary installation failed with error 1.
*** Aborting...

If I set
resolver: 7.16
I get:

--- Setting up GHC if needed...
Could not parse '/home/torstein/.stack/global-project/stack.yaml':
Aeson exception:
Error in $.resolver: failed to parse field 'resolver': Invalid Resolver, must be Object or String
See http://docs.haskellstack.org/en/stable/yaml_configuration/
*** Stack setup failed with error 1.
*** Aborting...

[jship]

I hit this too and am working on a PR for it.