Is it worth switching from Stack to Cabal?

#43

I see. Currently, Stack’s working directory for mutable/local packages is located relative to a project’s root directory. So, if you have, essentially, two separate projects (even if there is a lot of overlap in their code), Stack will have a separate working directory for each one. Stack only has a global store for packages considered to be immutable.

EDIT: There are Stack issues discussing this: Support non-relative STACK_WORK directory · Issue #6191 · commercialhaskell/stack · GitHub (where @hasufell offered a workaround) and Allow setting the working-dir to absolute directories · Issue #6135 · commercialhaskell/stack · GitHub (the main issue for its discussion).

2 Likes
#44

I guess that package which are given with a specific version (git repo + commit) in the stack.yml are considered “mutable” .
Also the doc of immutable package seems to be per project.
(I checked and when I said 2 or 3 Gb it is actuall 6Gb per project).

1 Like
#45

Doesnt cabal have the dist or dist-newstyle directories? Isn’t stack-work storing the same as those directories?

1 Like
#46

I don’t know. I don’t use cabal directly (or is stack using cabal under the hood ?)

1 Like
#47

I think that if a package is specified as a local filepath to a project directory, it is considered ‘mutable’. If a package is specified as a local filepath to an archive file (one option under extra-deps:), it is considered ‘immutable’. That is based on Build overview - The Haskell Tool Stack (warning: not wholly reliable).

I’m not sure that is correct, about the documentation of an ‘immutable’ package - I’ll see if I can track down a definitive answer.

On subsequent questions: both Stack and Cabal (the tool) are built on top of Cabal (the library). In the case of Stack, the build artefacts of Cabal (the library) are put in a dist\<hash> directory in .stack-work; the directory reported by the command stack path --dist-dir.

1 Like
#48

It seems that in my case most of the Gbs are taking by the doc (not sure why it is generated, probably me using stack hoogle). The doc of immutable packages seem to be in .stack-work (not ~/.stack).

#49

For me, something I really value about stack is the ability to swap out a package upstream for a version on my filesystem. (E: or a version on github rather than on hackage, or something.) I don’t have to do this very often, but when I do it’s incredibly helpful. It’s very easy with stack and I wouldn’t know how to do it with cabal. (And relatedly, at work I don’t know how to do it with my team’s nix+stack setup; in those situations I just drop myself out of nix temporarily.)

2 Likes
#50

That is a good point.

#51

That’s also easy with a cabal.project file, see:

  • 7.2. Specifying the local packages

    All local packages are vendored, in the sense that if other packages (including external ones from Hackage) depend on a package with the name of a local package, the local package is preferentially used. For subdirectories to be considered local packages, the following setting can be used:

    packages: ./*.cabal
optional-packages: ./*/*.cabal

    …then any package can be vendored simply by making a checkout in the top-level project directory, as might be seen in this hypothetical directory layout:

    foo.cabal
foo-helper/     # local package
unix/           # vendored external package

  • 7.2.1. Specifying Packages from Remote Version Control Locations

    Starting with Cabal 2.4, there is now a stanza source-repository-package for specifying packages from an external version control.

    packages: .

source-repository-package
    type: git
    location: https://github.com/hvr/HsYAML.git
    tag: e70cf0c171c9a586b62b3f75d72f1591e4e6aaa1

source-repository-package
    type: git
    location: https://github.com/well-typed/cborg
    tag: 3d274c14ca3077c3a081ba7ad57c5182da65c8c1
    subdir: cborg

source-repository-package
    type: git
    location: https://github.com/haskell/network.git
    tag: e76fdc753e660dfa615af6c8b6a2ad9ddf6afe70
    post-checkout-command: autoreconf -i
11 Likes