stack VS ghcid

Ah, didn't run into this issue, as I don't use vscode.

Apparently there is some work being done to improve the stack <> hls experience, but I wouldn't know how it's going and when it's being delivered: https://github.com/commercialhaskell/stack/issues/6154

this is it: # This file was automatically generated by 'stack init' # # Some commonly used options have been documented as comments in this file. # For advanced use and comprehensive documentation of the format, please see: # https://docs.haskellstack.org/en/stable/yaml\_configuration/ # Resolver to choose a 'specific' stackage snapshot or a compiler version. # A snapshot resolver dictates the compiler version and the set of packages # to be used for project dependencies. For example: # # resolver: lts-3.5 # resolver: nightly-2015-09-21 # resolver: ghc-7.10.2 # # The location of a snapshot can be provided as a file or url. Stack assumes # a snapshot provided as a file might change, whereas a url resource does not. # # resolver: ./custom-snapshot.yaml # resolver: https://example.com/snapshots/2018-01-01.yaml resolver: url: https://raw.githubusercontent.com/commercialhaskell/stackage-snapshots/master/lts/20/23.yaml # User packages to be built. # Various formats can be used as shown in the example below. # # packages: # - some-directory # - https://example.com/foo/bar/baz-0.0.2.tar.gz # subdirs: # - auto-update # - wai packages: - xmonad - xmonad-contrib # Dependency packages to be pulled from upstream that are not in the resolver. # These entries can reference officially published versions as well as # forks / in-progress versions pinned to a git hash. For example: # # extra-deps: # - acme-missiles-0.3 # - git: https://github.com/commercialhaskell/stack.git # commit: e7b331f14bcffb8367cd58fbfc8b40ec7642100a # # extra-deps: [] # Override default flag values for local packages and extra-deps # flags: {} # Extra package databases containing global packages # extra-package-dbs: [] # Control whether we use the GHC we find on the path # system-ghc: true # # Require a specific version of Stack, using version ranges # require-stack-version: -any # Default # require-stack-version: ">=2.11" # # Override the architecture used by Stack, especially useful on Windows # arch: i386 # arch: x86_64 # # Extra directories used by Stack for building # extra-include-dirs: [/path/to/dir] # extra-lib-dirs: [/path/to/dir] # # Allow a newer minor version of GHC than the snapshot specifies # compiler-check: newer-minor

Fix incorrect warning if allow-newer-deps are specified but allow-newer is false. See #6068.

You can download binaries for this pre-release from: Release rc/v2.11.0.1 (release candidate) · commercialhaskell/stack · GitHub .

Fair enough! Thanks for the suggestion, then. In fact, the non-Python language I develop most in (Haskell, with the Stack package manager) has exactly that behaviour as a default: new packages are installed to a sandboxed local directory, and it takes an explicit request to install something globally. (And even then, you can switch between different global "known good configurations" of package versions which work well together – a pretty handy feature.)

Opened a ticket on GitHub.

In YAML configuration files, the hackage-security key of the package-index key or the package-indices item can be omitted, and the Hackage Security configuration for the item will default to that for the official Hackage server. See #5870.

FYI this was solved in here: https://github.com/commercialhaskell/stack/issues/5958

Yes, that is correct. Stack's allow-newer: true configuration has always actually meant 'ignore bounds'. However, the author of the allow-newer-deps development has in mind a further development that will introduce an actual ignore-bounds key with the same expressive syntax that is used by Cabal. This is discussed at Stack #5910.

You can use ghcid. It compiles the code, and shows if there are any errors as you save your file. Have two terminals. One for editing your file...other one with ghcid ($ ghcid path/to/filename.hs). Right click on the ghcid terminal and click `always on top`. That way, It will be always visible as you are typing and saving code.

With a combination of ghcid, an hiedb filewatcher and the -fdefer-type-errors flag you can get pretty solid IDE behavior. Currently only ghc 9.4.4 is supported but happy to personally help people set this up if interested!

With an editor integration, you could rig it up to where you could right-click on a Spec, choose "Run spec" from a context menu, and have your editor add that comment to and save dev.hs. Another editor integration could read and parse the contents of ghcid.txt. We have this already for the compiler output, but it doesn't yet parse the test output. But sans an editor integration, you will still see the test output in the console where Ghcid is running.

Sounds like you want ghcid. You can use it run tests on a successful build, and it will watch files in your project and quick-rebuild when there are changes. There shouldn't be any need to modify your Cabal files or test dependencies.

In addition, for Haskell, I usually have ghcid running, which likewise re-runs on every file change, but gives faster feedback about any type errors than the full compiler, and also is configured to evaluate

Have you looked into ghcid? https://github.com/ndmitchell/ghcid

VS Code + Haskell extension is usually best, but ghcid is an alternative which is much simpler, easier to set up, less pretty and powerful but still pretty easy and effective to use. Here's a workflow:

In general, though, I recommend just looking at the cabal files for various libraries and executables. Something like ghcid is good, since it contains a library, an executable, and a test suite.

you should also checkout the ghci vim plugin https://github.com/ndmitchell/ghcid/tree/master/plugins/nvim