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.
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).
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.
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).
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.)
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:
…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